Re: [FFmpeg-devel] [PATCH v2 1/1] avformat: Add IPFS protocol support.
2 Feb 2022, 03:51 by mark...@gmail.com: > On Wed, Feb 2, 2022 at 3:29 AM Lynne wrote: > >> 1 Feb 2022, 22:58 by mark...@gmail.com: >> >> > This patch adds support for: >> > - ffplay ipfs:// >> > - ffplay ipns:// >> > >> > IPFS data can be played from so called "ipfs gateways". >> > A gateway is essentially a webserver that gives access to the >> > distributed IPFS network. >> > >> > This protocol support (ipfs and ipns) therefore translates >> > ipfs:// and ipns:// to a http:// url. This resulting url is >> > then handled by the http protocol. It could also be https >> > depending on the gateway provided. >> > >> > To use this protocol, a gateway must be provided. >> > If you do nothing it will try to find it in your >> > $HOME/.ipfs/gateway file. The ways to set it manually are: >> > 1. Define a -gateway to the gateway. >> > 2. Define $IPFS_GATEWAY with the full http link to the gateway. >> > 3. Define $IPFS_PATH and point it to the IPFS data path. >> > 4. Have IPFS running in your local user folder (under $HOME/.ipfs). >> > >> > Signed-off-by: Mark Gaiser >> > --- >> > configure | 2 + >> > doc/protocols.texi| 30 + >> > libavformat/Makefile | 2 + >> > libavformat/ipfsgateway.c | 267 ++ >> > libavformat/protocols.c | 2 + >> > 5 files changed, 303 insertions(+) >> > create mode 100644 libavformat/ipfsgateway.c >> > >> >> Fix all the coding style issues first... >> > Any hints on those? As I thought it was matching the other files (looking > at crypto.c) nicely. > https://ffmpeg.org/developer.html#Coding-Rules-1 And we also don't wrap single-line statements in blocks. ___ 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] libswscale: Re-factor ff_shuffle_filter_coefficients.
Hi,
Is anybody interested in this patch set?
Thanks!
On Mon, Jan 10, 2022, 15:58 Alan Kelly wrote:
> Make the code more readable, follow the style guide and propagate memory
> allocation errors.
> ---
> libswscale/swscale_internal.h | 2 +-
> libswscale/utils.c| 68 ---
> 2 files changed, 40 insertions(+), 30 deletions(-)
>
> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
> index 3a78d95ba6..26d28d42e6 100644
> --- a/libswscale/swscale_internal.h
> +++ b/libswscale/swscale_internal.h
> @@ -1144,5 +1144,5 @@ void ff_sws_slice_worker(void *priv, int jobnr, int
> threadnr,
> #define MAX_LINES_AHEAD 4
>
> //shuffle filter and filterPos for hyScale and hcScale filters in avx2
> -void ff_shuffle_filter_coefficients(SwsContext *c, int* filterPos, int
> filterSize, int16_t *filter, int dstW);
> +int ff_shuffle_filter_coefficients(SwsContext *c, int* filterPos, int
> filterSize, int16_t *filter, int dstW);
> #endif /* SWSCALE_SWSCALE_INTERNAL_H */
> diff --git a/libswscale/utils.c b/libswscale/utils.c
> index c5ea8853d5..52f07e1661 100644
> --- a/libswscale/utils.c
> +++ b/libswscale/utils.c
> @@ -278,39 +278,47 @@ static const FormatEntry format_entries[] = {
> [AV_PIX_FMT_P416LE] = { 1, 1 },
> };
>
> -void ff_shuffle_filter_coefficients(SwsContext *c, int *filterPos, int
> filterSize, int16_t *filter, int dstW){
> +int ff_shuffle_filter_coefficients(SwsContext *c, int *filterPos,
> + int filterSize, int16_t *filter,
> + int dstW)
> +{
> #if ARCH_X86_64
> -int i, j, k, l;
> +int i = 0, j = 0, k = 0;
> int cpu_flags = av_get_cpu_flags();
> +if (!filter || dstW % 16 != 0) return 0;
> if (EXTERNAL_AVX2_FAST(cpu_flags) && !(cpu_flags &
> AV_CPU_FLAG_SLOW_GATHER)) {
> -if ((c->srcBpc == 8) && (c->dstBpc <= 14)){
> -if (dstW % 16 == 0){
> -if (filter != NULL){
> -for (i = 0; i < dstW; i += 8){
> -FFSWAP(int, filterPos[i + 2], filterPos[i+4]);
> -FFSWAP(int, filterPos[i + 3], filterPos[i+5]);
> -}
> -if (filterSize > 4){
> -int16_t *tmp2 = av_malloc(dstW * filterSize * 2);
> -memcpy(tmp2, filter, dstW * filterSize * 2);
> -for (i = 0; i < dstW; i += 16){//pixel
> -for (k = 0; k < filterSize / 4; ++k){//fcoeff
> -for (j = 0; j < 16; ++j){//inner pixel
> -for (l = 0; l < 4; ++l){//coeff
> -int from = i * filterSize + j *
> filterSize + k * 4 + l;
> -int to = (i) * filterSize + j * 4
> + l + k * 64;
> -filter[to] = tmp2[from];
> -}
> -}
> -}
> -}
> -av_free(tmp2);
> -}
> -}
> -}
> +if ((c->srcBpc == 8) && (c->dstBpc <= 14)) {
> + int16_t *filterCopy = NULL;
> + if (filterSize > 4) {
> + if (!FF_ALLOC_TYPED_ARRAY(filterCopy, dstW * filterSize))
> + return AVERROR(ENOMEM);
> + memcpy(filterCopy, filter, dstW * filterSize *
> sizeof(int16_t));
> + }
> + // Do not swap filterPos for pixels which won't be processed by
> + // the main loop.
> + for (i = 0; i + 8 <= dstW; i += 8) {
> + FFSWAP(int, filterPos[i + 2], filterPos[i + 4]);
> + FFSWAP(int, filterPos[i + 3], filterPos[i + 5]);
> + }
> + if (filterSize > 4) {
> + // 16 pixels are processed at a time.
> + for (i = 0; i + 16 <= dstW; i += 16) {
> + // 4 filter coeffs are processed at a time.
> + for (k = 0; k + 4 <= filterSize; k += 4) {
> + for (j = 0; j < 16; ++j) {
> + int from = (i + j) * filterSize + k;
> + int to = i * filterSize + j * 4 + k * 16;
> + memcpy(&filter[to], &filterCopy[from], 4 *
> sizeof(int16_t));
> + }
> + }
> + }
> + }
> + if (filterCopy)
> + av_free(filterCopy);
> }
> }
> #endif
> +return 0;
> }
>
> int sws_isSupportedInput(enum AVPixelFormat pix_fmt)
> @@ -1836,7 +1844,8 @@ av_cold int sws_init_context(SwsContext *c,
> SwsFilter *srcFilter,
> get_local_pos(c, 0, 0, 0),
> get_local_pos(c, 0, 0, 0))) < 0)
> goto fail;
> -ff_shuffle_filter_coefficien
Re: [FFmpeg-devel] [PATCH 0/5] Add IPFS and IPNS protocol support
tis 2022-02-01 klockan 22:18 +0100 skrev Mark Gaiser: > > To give you an idea of how it looks. Kodi has so called strm (stream) > files. They can contain an url that can be played. > > Without this patch an ipfs file would look like this: > > http://localhost:8080/ipfs/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > With this patch it becomes possible to patch kodi to accept: > ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > In the former case it's gateway specific. In the latter case it's > gateway > agnostic. > > The gateway specific way has a problem. If i translate it to a > gateway then > that url i picked becomes the point to access the file. > If that url goes down, the file isn't playable. Even if the file > might > still be online just fine on the IPFS network. > Imagine you get a file from me and have ipfs running locally. I'm > guessing > you don't like to edit the file you received to fix the gateway part > of the > url, do you? I certainly don't. You translate the URLs on the fly of course, and don't store the translated URLs in the strm. I can almost guarantee you you will need to do this inside Kodi anyway. What if you want to play a playlist stored in IPFS? /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/1] avformat: Add IPFS protocol support.
tis 2022-02-01 klockan 22:58 +0100 skrev Mark Gaiser:
>
> +typedef struct Context {
> + AVClass *class;
> + URLContext *inner;
> + char *gateway;
Is there not a maximum length that an HTTP URL can be? At least without
query parameters. That way you avoid dynamic allocations. You'd have to
separate the AVOption from such a buffer in that case, but I think you
have to anyway.
> + if (!ipfs_full_data_folder) {
> + av_log(h, AV_LOG_DEBUG, "$IPFS_PATH is empty.\n");
> +
> + // Try via the home folder.
> + home_folder = getenv("HOME");
> + ipfs_full_data_folder = av_asprintf("%s/.ipfs/",
> home_folder);
Memory leak. This applies to most if not all av_asprintf() calls.
> +
> + // Stat the folder. It should exist in a default IPFS setup
> when run as local user.
> +#ifndef _WIN32
> + stat_ret = stat(ipfs_full_data_folder, &st);
> +#else
> + stat_ret = win32_stat(ipfs_full_data_folder, &st);
> +#endif
Why bother with stat() when you can just check whether fopen()
succeeded?
> +// For now just makes sure that the gateway ends in url we expect.
> Like http://localhost:8080/.
> +// Explicitly with the traling slash.
> +static void ff_sanitize_ipfs_gateway(URLContext *h)
> +{
> + Context *c = h->priv_data;
> + const char last_gateway_char = c->gateway[strlen(c->gateway) -
> 1];
Can strlen(c->gateway) be zero here?
> +static int translate_ipfs_to_http(URLContext *h, const char *uri,
> int flags, AVDictionary **options)
> +{
> + const char *ipfs_cid;
> + const char *protocol_path_suffix = "ipfs/";
> + char *fulluri;
> + int ret;
> + Context *c = h->priv_data;
> + int is_ipfs = (av_strstart(uri, "ipfs://", &ipfs_cid) ||
> av_strstart(uri, "ipfs:", &ipfs_cid));
> + int is_ipns = (av_strstart(uri, "ipns://", &ipfs_cid) ||
> av_strstart(uri, "ipns:", &ipfs_cid));
https://docs.ipfs.io/concepts/ipfs-gateway/ claims ipfs:// is the
canonical form. No mentioned is made of any ipfs:{CID} form. Incorrect
URLs should be rejected, not silently patched.
Also what happens if c->gateway is "ipfs://[...]"? Infinite recursion?
/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/1] avformat: Add IPFS protocol support.
On Tue, Feb 01, 2022 at 10:58:30PM +0100, Mark Gaiser wrote: > This patch adds support for: > - ffplay ipfs:// > - ffplay ipns:// > > IPFS data can be played from so called "ipfs gateways". > A gateway is essentially a webserver that gives access to the > distributed IPFS network. > > This protocol support (ipfs and ipns) therefore translates > ipfs:// and ipns:// to a http:// url. This resulting url is > then handled by the http protocol. It could also be https > depending on the gateway provided. > > To use this protocol, a gateway must be provided. > If you do nothing it will try to find it in your > $HOME/.ipfs/gateway file. The ways to set it manually are: > 1. Define a -gateway to the gateway. > 2. Define $IPFS_GATEWAY with the full http link to the gateway. > 3. Define $IPFS_PATH and point it to the IPFS data path. > 4. Have IPFS running in your local user folder (under $HOME/.ipfs). > > Signed-off-by: Mark Gaiser > --- > configure | 2 + > doc/protocols.texi| 30 + > libavformat/Makefile | 2 + > libavformat/ipfsgateway.c | 267 ++ > libavformat/protocols.c | 2 + > 5 files changed, 303 insertions(+) > create mode 100644 libavformat/ipfsgateway.c > > diff --git a/configure b/configure > index 5b19a35f59..6ff09e7974 100755 > --- a/configure > +++ b/configure > @@ -3585,6 +3585,8 @@ udp_protocol_select="network" > udplite_protocol_select="network" > unix_protocol_deps="sys_un_h" > unix_protocol_select="network" > +ipfs_protocol_select="https_protocol" > +ipns_protocol_select="https_protocol" > > # external library protocols > libamqp_protocol_deps="librabbitmq" > diff --git a/doc/protocols.texi b/doc/protocols.texi > index d207df0b52..7c9c0a4808 100644 > --- a/doc/protocols.texi > +++ b/doc/protocols.texi > @@ -2025,5 +2025,35 @@ decoding errors. > > @end table > > +@section ipfs > + > +InterPlanetary File System (IPFS) protocol support. One can access files > stored > +on the IPFS network through so called gateways. Those are http(s) endpoints. > +This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to be > send > +to such a gateway. Users can (and should) host their own node which means > this > +protocol will use your local machine gateway to access files on the IPFS > network. > + > +If a user doesn't have a node of their own then the public gateway dweb.link > is > +used by default. > + > +You can use this protocol in 2 ways. Using IPFS: > +@example > +ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +Or the IPNS protocol (IPNS is mutable IPFS): > +@example > +ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +You can also change the gateway to be used: > + > +@table @option > + > +@item gateway > +Defines the gateway to use. When nothing is provided the protocol will first > try > +your local gateway. If that fails dweb.link will be used. > + > +@end table > > @c man end PROTOCOLS > diff --git a/libavformat/Makefile b/libavformat/Makefile > index 3dc6a479cc..4edce8420f 100644 > --- a/libavformat/Makefile > +++ b/libavformat/Makefile > @@ -656,6 +656,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += srtpproto.o > srtp.o > OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o > OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o > OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o > +OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o > +OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o > TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o > TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o > TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o > diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c > new file mode 100644 > index 00..2b52fc9392 > --- /dev/null > +++ b/libavformat/ipfsgateway.c > @@ -0,0 +1,267 @@ > +/* > + * IPFS and IPNS protocol support through IPFS Gateway. > + * Copyright (c) 2022 Mark Gaiser > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 > USA > + */ > + > +#include "libavutil/avassert.h" > +#include "libavutil/avstring.h" > +#include "libavutil/internal.h" > +#include
Re: [FFmpeg-devel] [PATCH 0/5] Add IPFS and IPNS protocol support
On Wed, Feb 2, 2022 at 1:52 PM Tomas Härdin wrote: > tis 2022-02-01 klockan 22:18 +0100 skrev Mark Gaiser: > > > > To give you an idea of how it looks. Kodi has so called strm (stream) > > files. They can contain an url that can be played. > > > > Without this patch an ipfs file would look like this: > > > > > http://localhost:8080/ipfs/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > > > With this patch it becomes possible to patch kodi to accept: > > ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > > > In the former case it's gateway specific. In the latter case it's > > gateway > > agnostic. > > > > The gateway specific way has a problem. If i translate it to a > > gateway then > > that url i picked becomes the point to access the file. > > If that url goes down, the file isn't playable. Even if the file > > might > > still be online just fine on the IPFS network. > > Imagine you get a file from me and have ipfs running locally. I'm > > guessing > > you don't like to edit the file you received to fix the gateway part > > of the > > url, do you? I certainly don't. > > You translate the URLs on the fly of course, and don't store the > translated URLs in the strm. I can almost guarantee you you will need > to do this inside Kodi anyway. What if you want to play a playlist > stored in IPFS? > I can guarantee Kodi won't need to do that translation if it's in ffmpeg. This is because kodi passes media on to ffmpeg. If ipfs and ipns are in it's whitelisted protocols then ffmpeg is relied upon to handle it. It's not "exactly" working like that (there are many layers there) but it's roughly how it works. We are getting out of the ffmpeg scope here, but here's how I envision it to work in kodi. I'm quite sure it's going to work this way because I'm making the patches for it :) How I envision it is as follows: 1. Kodi will, somewhere in it's settings, get an option to define an IPFS gateway. If the user specifies this, it's used. 2. ffmpeg will just honor what was set (kodi will likely pass -gateway ) or will try to auto detect if nothing is given. 3. strm files will be modified to work with ipfs:// url's 4. playlist files. These are tricky as they are not specific to kodi. I will TRY to let those work if they contain ipfs:// The playlist case is a bit tricky as m3u8 (i assume you mean that) isn't a kodi specific thing. strm is. The eventual endgoal with regards to kodi is for ipfs:// to be a first-class citizen and to just work. But there are lots of places in kodi that i'll need to adjust for that to become a reality. The first step is to get it working in the strm file and I'll go from there. > > /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 0/5] Add IPFS and IPNS protocol support
On Tue, Feb 01, 2022 at 05:43:24PM +0100, Tomas Härdin wrote: > tis 2022-02-01 klockan 11:06 +0100 skrev Michael Niedermayer: > > On Mon, Jan 31, 2022 at 09:22:52PM +0100, Tomas Härdin wrote: > > [...] > > > It strikes me that this borders on incorporating business logic > > > within > > > lavf. A user could achieve the same thing with a small shell > > > script. > > > For example adding an alias that inspects calls to ffmpeg and sed:s > > > ipfs:// URLs accordingly > > > > That sounds like a security nightmare > > Parsing shit in C is a far bigger nightmare I can assure you. The > command line can leverage sed and the regex in the URL RFC. the problem is if you parse it on the command line and change it before passing it to ffmpeg. You really need to have ffmpeg and the command line parse it 100% exactly the same. If theres a difference you can introduce security issues. because things in the commend line that are not intended to be changed by an attacker could become changeable by parser differences, this involves also issues with artgument seperators being parsed or not parsed as urls for example a filter argument could be a URL or it could be a generic string the command line wraper would have to know this difference. metadata and drawtext will behave interresting if they display ipfs: and keep in mind on top here the : is a argument seperator for filters so a real url ipfs link as filter argument would have the : escaped in some way. The command line tool would need to fully handle all escaping and unescping we use in every argument and it would need to have a list of what holds an url and what doesnt. Noone will implement this in a 100% correct form with sed and regex anyone trying will long before run naked through the streets and flap her/his hands as if (s)he is a chicken feel free to proof me wrong of course thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA 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 v2 1/1] avformat: Add IPFS protocol support.
On Wed, Feb 2, 2022 at 2:21 PM Tomas Härdin wrote:
> tis 2022-02-01 klockan 22:58 +0100 skrev Mark Gaiser:
>
> >
> > +typedef struct Context {
> > +AVClass *class;
> > +URLContext *inner;
> > +char *gateway;
>
> Is there not a maximum length that an HTTP URL can be? At least without
> query parameters. That way you avoid dynamic allocations. You'd have to
> separate the AVOption from such a buffer in that case, but I think you
> have to anyway.
>
Could you provide more information on that? Or an example of what you mean
exactly?
As far as i know there is no hard limit though it's very much advised to
not go above 2048 characters.
>
> > +if (!ipfs_full_data_folder) {
> > +av_log(h, AV_LOG_DEBUG, "$IPFS_PATH is empty.\n");
> > +
> > +// Try via the home folder.
> > +home_folder = getenv("HOME");
> > +ipfs_full_data_folder = av_asprintf("%s/.ipfs/",
> > home_folder);
>
> Memory leak. This applies to most if not all av_asprintf() calls.
>
Is there an advised way to neatly clean that up?
Sure, I can add a bunch of av_free calls to clean it up. But there are
places where it's not as straightforward like where the av_asprintf was
done in an if statement. How do I maintain the knowledge that av_asprintf
was used to call av_free later?
In a C++ world I'd use a scoped variable ;) But I kinda miss how to do that
properly here.
> > +
> > +// Stat the folder. It should exist in a default IPFS setup
> > when run as local user.
> > +#ifndef _WIN32
> > +stat_ret = stat(ipfs_full_data_folder, &st);
> > +#else
> > +stat_ret = win32_stat(ipfs_full_data_folder, &st);
> > +#endif
>
> Why bother with stat() when you can just check whether fopen()
> succeeded?
>
Ohh! Nice one!
It doesn't make the code shorter or easier though. But does get rid of
platform dependent stuff so a win imho anyhow.
>
> > +// For now just makes sure that the gateway ends in url we expect.
> > Like http://localhost:8080/.
> > +// Explicitly with the traling slash.
> > +static void ff_sanitize_ipfs_gateway(URLContext *h)
> > +{
> > +Context *c = h->priv_data;
> > +const char last_gateway_char = c->gateway[strlen(c->gateway) -
> > 1];
>
> Can strlen(c->gateway) be zero here?
>
Hmm, potentially yes. I'll add a check for it.
>
> > +static int translate_ipfs_to_http(URLContext *h, const char *uri,
> > int flags, AVDictionary **options)
> > +{
> > +const char *ipfs_cid;
> > +const char *protocol_path_suffix = "ipfs/";
> > +char *fulluri;
> > +int ret;
> > +Context *c = h->priv_data;
> > +int is_ipfs = (av_strstart(uri, "ipfs://", &ipfs_cid) ||
> > av_strstart(uri, "ipfs:", &ipfs_cid));
> > +int is_ipns = (av_strstart(uri, "ipns://", &ipfs_cid) ||
> > av_strstart(uri, "ipns:", &ipfs_cid));
>
> https://docs.ipfs.io/concepts/ipfs-gateway/ claims ipfs:// is the
> canonical form. No mentioned is made of any ipfs:{CID} form. Incorrect
> URLs should be rejected, not silently patched.
>
I'd like to make a decision here. This current logic (ipfs:// and ipfs:,
same for ipns) is inspired by other protocols that ffmpeg supported. I
simply copied how they work to be consistent.
Do i:
1. keep it as is and be consistent with the rest?
2. only allow ipfs:// and ipns://?
>
> Also what happens if c->gateway is "ipfs://[...]"? Infinite recursion?
>
Nice one, I need to test that!
>
> /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 1/1] avformat: Add IPFS protocol support.
On 02.02.2022 14:56, Mark Gaiser wrote:
On Wed, Feb 2, 2022 at 2:21 PM Tomas Härdin wrote:
tis 2022-02-01 klockan 22:58 +0100 skrev Mark Gaiser:
+typedef struct Context {
+AVClass *class;
+URLContext *inner;
+char *gateway;
Is there not a maximum length that an HTTP URL can be? At least without
query parameters. That way you avoid dynamic allocations. You'd have to
separate the AVOption from such a buffer in that case, but I think you
have to anyway.
Could you provide more information on that? Or an example of what you mean
exactly?
As far as i know there is no hard limit though it's very much advised to
not go above 2048 characters.
+if (!ipfs_full_data_folder) {
+av_log(h, AV_LOG_DEBUG, "$IPFS_PATH is empty.\n");
+
+// Try via the home folder.
+home_folder = getenv("HOME");
+ipfs_full_data_folder = av_asprintf("%s/.ipfs/",
home_folder);
Memory leak. This applies to most if not all av_asprintf() calls.
Is there an advised way to neatly clean that up?
Sure, I can add a bunch of av_free calls to clean it up. But there are
places where it's not as straightforward like where the av_asprintf was
done in an if statement. How do I maintain the knowledge that av_asprintf
was used to call av_free later?
In a C++ world I'd use a scoped variable ;) But I kinda miss how to do that
properly here.
You typically make a "goto error" style thing, where you free everything
that might have been allocated.
Freeing a NULL pointer is valid and does not cause issues, so just
properly initialize the pointers and av_freep() them on error.
smime.p7s
Description: S/MIME Cryptographic 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 v2 1/1] avformat: Add IPFS protocol support.
On Wed, Feb 2, 2022 at 2:29 PM Michael Niedermayer wrote: > On Tue, Feb 01, 2022 at 10:58:30PM +0100, Mark Gaiser wrote: > > This patch adds support for: > > - ffplay ipfs:// > > - ffplay ipns:// > > > > IPFS data can be played from so called "ipfs gateways". > > A gateway is essentially a webserver that gives access to the > > distributed IPFS network. > > > > This protocol support (ipfs and ipns) therefore translates > > ipfs:// and ipns:// to a http:// url. This resulting url is > > then handled by the http protocol. It could also be https > > depending on the gateway provided. > > > > To use this protocol, a gateway must be provided. > > If you do nothing it will try to find it in your > > $HOME/.ipfs/gateway file. The ways to set it manually are: > > 1. Define a -gateway to the gateway. > > 2. Define $IPFS_GATEWAY with the full http link to the gateway. > > 3. Define $IPFS_PATH and point it to the IPFS data path. > > 4. Have IPFS running in your local user folder (under $HOME/.ipfs). > > > > Signed-off-by: Mark Gaiser > > --- > > configure | 2 + > > doc/protocols.texi| 30 + > > libavformat/Makefile | 2 + > > libavformat/ipfsgateway.c | 267 ++ > > libavformat/protocols.c | 2 + > > 5 files changed, 303 insertions(+) > > create mode 100644 libavformat/ipfsgateway.c > > > > diff --git a/configure b/configure > > index 5b19a35f59..6ff09e7974 100755 > > --- a/configure > > +++ b/configure > > @@ -3585,6 +3585,8 @@ udp_protocol_select="network" > > udplite_protocol_select="network" > > unix_protocol_deps="sys_un_h" > > unix_protocol_select="network" > > +ipfs_protocol_select="https_protocol" > > +ipns_protocol_select="https_protocol" > > > > # external library protocols > > libamqp_protocol_deps="librabbitmq" > > diff --git a/doc/protocols.texi b/doc/protocols.texi > > index d207df0b52..7c9c0a4808 100644 > > --- a/doc/protocols.texi > > +++ b/doc/protocols.texi > > @@ -2025,5 +2025,35 @@ decoding errors. > > > > @end table > > > > +@section ipfs > > + > > +InterPlanetary File System (IPFS) protocol support. One can access > files stored > > +on the IPFS network through so called gateways. Those are http(s) > endpoints. > > +This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to > be send > > +to such a gateway. Users can (and should) host their own node which > means this > > +protocol will use your local machine gateway to access files on the > IPFS network. > > + > > +If a user doesn't have a node of their own then the public gateway > dweb.link is > > +used by default. > > + > > +You can use this protocol in 2 ways. Using IPFS: > > +@example > > +ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > +@end example > > + > > +Or the IPNS protocol (IPNS is mutable IPFS): > > +@example > > +ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > +@end example > > + > > +You can also change the gateway to be used: > > + > > +@table @option > > + > > +@item gateway > > +Defines the gateway to use. When nothing is provided the protocol will > first try > > +your local gateway. If that fails dweb.link will be used. > > + > > +@end table > > > > @c man end PROTOCOLS > > diff --git a/libavformat/Makefile b/libavformat/Makefile > > index 3dc6a479cc..4edce8420f 100644 > > --- a/libavformat/Makefile > > +++ b/libavformat/Makefile > > @@ -656,6 +656,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += > srtpproto.o srtp.o > > OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o > > OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o > > OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o > > +OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o > > +OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o > > TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o > > TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o > > TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o > > diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c > > new file mode 100644 > > index 00..2b52fc9392 > > --- /dev/null > > +++ b/libavformat/ipfsgateway.c > > @@ -0,0 +1,267 @@ > > +/* > > + * IPFS and IPNS protocol support through IPFS Gateway. > > + * Copyright (c) 2022 Mark Gaiser > > + * > > + * This file is part of FFmpeg. > > + * > > + * FFmpeg is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU Lesser General Public > > + * License as published by the Free Software Foundation; either > > + * version 2.1 of the License, or (at your option) any later version. > > + * > > + * FFmpeg is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > > + * Lesser General Public License for more details. > > + * > > + * You should have received a copy of the GNU Lesser General Public > >
Re: [FFmpeg-devel] [PATCH v2 1/1] avformat: Add IPFS protocol support.
On Wed, Feb 2, 2022 at 3:24 PM Timo Rothenpieler
wrote:
> On 02.02.2022 14:56, Mark Gaiser wrote:
> > On Wed, Feb 2, 2022 at 2:21 PM Tomas Härdin wrote:
> >
> >> tis 2022-02-01 klockan 22:58 +0100 skrev Mark Gaiser:
> >>
> >>>
> >>> +typedef struct Context {
> >>> +AVClass *class;
> >>> +URLContext *inner;
> >>> +char *gateway;
> >>
> >> Is there not a maximum length that an HTTP URL can be? At least without
> >> query parameters. That way you avoid dynamic allocations. You'd have to
> >> separate the AVOption from such a buffer in that case, but I think you
> >> have to anyway.
> >>
> >
> > Could you provide more information on that? Or an example of what you
> mean
> > exactly?
> > As far as i know there is no hard limit though it's very much advised to
> > not go above 2048 characters.
> >
> >>
> >>> +if (!ipfs_full_data_folder) {
> >>> +av_log(h, AV_LOG_DEBUG, "$IPFS_PATH is empty.\n");
> >>> +
> >>> +// Try via the home folder.
> >>> +home_folder = getenv("HOME");
> >>> +ipfs_full_data_folder = av_asprintf("%s/.ipfs/",
> >>> home_folder);
> >>
> >> Memory leak. This applies to most if not all av_asprintf() calls.
> >>
> >
> > Is there an advised way to neatly clean that up?
> > Sure, I can add a bunch of av_free calls to clean it up. But there are
> > places where it's not as straightforward like where the av_asprintf was
> > done in an if statement. How do I maintain the knowledge that av_asprintf
> > was used to call av_free later?
> > In a C++ world I'd use a scoped variable ;) But I kinda miss how to do
> that
> > properly here.
>
> You typically make a "goto error" style thing, where you free everything
> that might have been allocated.
> Freeing a NULL pointer is valid and does not cause issues, so just
> properly initialize the pointers and av_freep() them on error.
>
Awesome! Thank you for explaining it, fixing it now.
> ___
> 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] avformat/mkv: add mkv tags for AVS2 and AVS3 codecs.
Let’s merge it.
From: Ze Yuan
Sent: Tuesday, February 1, 2022 12:36 PM
To: ffmpeg-devel
Subject: [FFmpeg-devel] avformat/mkv: add mkv tags for AVS2 and AVS3 codecs.
From babcceafbd30eff677b2366a0c470d31c503bed1 Mon Sep 17 00:00:00 2001
From: TianBo Zheng
Date: Mon, 10 Jan 2022 11:18:56 +
Subject: [PATCH] avformat/mkv: add mkv tags for AVS2 and AVS3 codecs.
MKV codec mappings:
V_AVS2 and V_AVS3
(https://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec_specs.md)
Encoding tool:
Ffmpeg with AVS2/AVS3 enabled:
https://github.com/xatabhk/FFmpeg-avs2-avs3/releases
Command line:
ffmpeg -i .mp4 -vcodec avs2 -acodec copy _avs2.mkv
ffmpeg -i .mp4 -vcodec avs2 -speed_level 4 -acodec copy
_avs2.mkv`
Players:
(1) Ffmpeg with avs2/avs3 enabled:
(https://github.com/xatabhk/FFmpeg-avs2-avs3/releases):
Command line:
ffplay _avs2.mkv
ffplay _avs3.mkv
(2) VLC 3.0.x with AVS2/AVS3 enabled:
https://github.com/xatabhk/vlc-3.0-avs2-avs3/releases
(3) Mpc-hc 1.9.x with AVS2/AVS3 enabled:
https://gitee.com/zhengtianbo/cavs-avs2-avs3_decoder_added_to_mpc_hc/releases
AVS2/AVS3 MKV samples:
https://github.com/xatabhk/avs2-avs3-video-samples
Signed-off-by: TianBo Zheng naturalwal...@hotmail.com
---
libavformat/matroska.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index 7c56aba403..90d94b65bf 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
@@ -78,6 +78,8 @@ const CodecTags ff_mkv_codec_tags[]={
{"S_HDMV/TEXTST", AV_CODEC_ID_HDMV_TEXT_SUBTITLE},
{"V_AV1", AV_CODEC_ID_AV1},
+{"V_AVS2" , AV_CODEC_ID_AVS2},
+{"V_AVS3" , AV_CODEC_ID_AVS3},
{"V_DIRAC" , AV_CODEC_ID_DIRAC},
{"V_FFV1" , AV_CODEC_ID_FFV1},
{"V_MJPEG" , AV_CODEC_ID_MJPEG},
--
2.19.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".
[FFmpeg-devel] fatal: Resolve operation not in progress, we are not resuming.
Hi, I am trying to apply this patch https://patchwork.ffmpeg.org/project/ffmpeg/patch/d412c54e-2e51-4522-a8fb-32c5c6ca6...@gettyimages.com/. I am able to `git apply` the patch locally and `make fate passes`, so I am not sure what I need to do to get this patch to not throw warnings. I have tried what is suggested in https://patchwork.ffmpeg.org/check/53886/. The results are… git am --show-current-patch=diff fatal: Resolve operation not in progress, we are not resuming. Any help would be appreciated. Thank you. Bryce Bryce Chester Newman | Principal Developer p: +12069255045 | ___ 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 v4] avformat/hls: Implement support for using AVSEEK_FLAG_BACKWARD when seeking
Any comments on this?
cheers,
Gustav
On Fri, Jan 28, 2022 at 9:24 PM Gustav Grusell
wrote:
> Before, seeking in hls streams would always seek to the next keyframe
> after the given timestamp. With this fix, if seeking in videostream and
> AVSEEK_FLAG_BACKWARD is set, seeking will be to the first keyframe of
> the segment containing the given timestamp. This fixes #7485.
>
> Signed-off-by: Gustav Grusell
> ---
> libavformat/hls.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 4568e72cb2..44afdaab42 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1653,7 +1653,8 @@ static void
> add_metadata_from_renditions(AVFormatContext *s, struct playlist *pl
> /* if timestamp was in valid range: returns 1 and sets seq_no
> * if not: returns 0 and sets seq_no to closest segment */
> static int find_timestamp_in_playlist(HLSContext *c, struct playlist *pls,
> - int64_t timestamp, int64_t *seq_no)
> + int64_t timestamp, int64_t *seq_no,
> + int64_t *seg_start_ts)
> {
> int i;
> int64_t pos = c->first_timestamp == AV_NOPTS_VALUE ?
> @@ -1668,6 +1669,9 @@ static int find_timestamp_in_playlist(HLSContext *c,
> struct playlist *pls,
> int64_t diff = pos + pls->segments[i]->duration - timestamp;
> if (diff > 0) {
> *seq_no = pls->start_seq_no + i;
> +if (seg_start_ts) {
> +*seg_start_ts = pos;
> +}
> return 1;
> }
> pos += pls->segments[i]->duration;
> @@ -1691,7 +1695,7 @@ static int64_t select_cur_seq_no(HLSContext *c,
> struct playlist *pls)
> * playlist) and this is a complete file, find the matching segment
> * by counting durations. */
> if (pls->finished && c->cur_timestamp != AV_NOPTS_VALUE) {
> -find_timestamp_in_playlist(c, pls, c->cur_timestamp, &seq_no);
> +find_timestamp_in_playlist(c, pls, c->cur_timestamp, &seq_no,
> NULL);
> return seq_no;
> }
>
> @@ -2362,7 +2366,7 @@ static int hls_read_seek(AVFormatContext *s, int
> stream_index,
> int i, j;
> int stream_subdemuxer_index;
> int64_t first_timestamp, seek_timestamp, duration;
> -int64_t seq_no;
> +int64_t seq_no, seg_start_ts;
>
> if ((flags & AVSEEK_FLAG_BYTE) || (c->ctx->ctx_flags &
> AVFMTCTX_UNSEEKABLE))
> return AVERROR(ENOSYS);
> @@ -2372,8 +2376,7 @@ static int hls_read_seek(AVFormatContext *s, int
> stream_index,
>
> seek_timestamp = av_rescale_rnd(timestamp, AV_TIME_BASE,
>
> s->streams[stream_index]->time_base.den,
> -flags & AVSEEK_FLAG_BACKWARD ?
> -AV_ROUND_DOWN : AV_ROUND_UP);
> +AV_ROUND_DOWN);
>
> duration = s->duration == AV_NOPTS_VALUE ?
> 0 : s->duration;
> @@ -2394,9 +2397,16 @@ static int hls_read_seek(AVFormatContext *s, int
> stream_index,
> }
> /* check if the timestamp is valid for the playlist with the
> * specified stream index */
> -if (!seek_pls || !find_timestamp_in_playlist(c, seek_pls,
> seek_timestamp, &seq_no))
> +if (!seek_pls || !find_timestamp_in_playlist(c, seek_pls,
> seek_timestamp, &seq_no, &seg_start_ts))
> return AVERROR(EIO);
>
> +if (s->streams[stream_index]->codecpar->codec_type ==
> AVMEDIA_TYPE_VIDEO &&
> +flags & AVSEEK_FLAG_BACKWARD && !(flags & AVSEEK_FLAG_ANY)) {
> +/* Seeking to start of segment ensures we seek to a keyframe
> located
> + * before the given timestamp. */
> +seek_timestamp = seg_start_ts;
> +}
> +
> /* set segment now so we do not need to search again below */
> seek_pls->cur_seq_no = seq_no;
> seek_pls->seek_stream_index = stream_subdemuxer_index;
> @@ -2423,7 +2433,7 @@ static int hls_read_seek(AVFormatContext *s, int
> stream_index,
>
> if (pls != seek_pls) {
> /* set closest segment seq_no for playlists not handled above
> */
> -find_timestamp_in_playlist(c, pls, seek_timestamp,
> &pls->cur_seq_no);
> +find_timestamp_in_playlist(c, pls, seek_timestamp,
> &pls->cur_seq_no, NULL);
> /* seek the playlist to the given position without taking
> * keyframes into account since this playlist does not have
> the
> * specified stream where we should look for the keyframes */
> --
> 2.25.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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
It appears my previous mail has been interpreted as some sort of attack against you; this is not the case. I am sorry for creating such a misunderstanding. The mail was merely meant to clear up the misconception that it would be impossible to send mixed line-endings via mail due to some SMTP property using some illustrative examples from the current thread. (I have no idea how SMTP works in detail) I'll respond to the new misunderstandings below in more detail if you're interested, but I see little point in continuing to discuss how mails are transferred or encoded. Can we now start to discuss the patches themselves instead? If you want to apply them and have trouble with getting the correct patch out of your client (and don't want to use Patchwork's diff), let me repeat my previous offer: > > If someone wants to apply the patches and has trouble with getting the patch > > out of the mailclient I can on request resend the patch with a binary diff > > for the reference file. ~~ On Wed, Feb 02, 2022 at 04:44:54 +, Soft Works wrote: > > It CAN be applied (as I've now written twice) and > > of course I verified this with the mail received from the list. > > I meant that it can be applied by everybody, including Patchwork > and Michael. Everybody but Patchwork can apply the mail and Patchwork's _diff_ works too. In case any mail client acts up I already offered to resend the patch with a binary flag for the reference file on request. > I use git format-patch, just like many others and afaik it can't create base64 > encoded content. It doesn't need to. When attaching a format-patch (as ffmpeg's documentation recommends when not using send-email) the _mail client_ is supposed to choose and perform a suitable transfer encoding. Depending on the mail client this can also work with the main message, but some clients have trouble preserving everything in the main message. (Because they assume the main body to be plain text and eg "normalise" line-ending, automatically break long lines, remove or replace special characters, etc) > BTW. BASE64 doesn't seem to be widely used here, [...] Note, that I wrote send-email uses the appropriate transfer-encoding “automatically” not “always base64”; if there are no characters in the message beyond US-ASCII (and mayhaps only LF line-endings), using base64 or quoted-printable is not necessary. Whether or not mixed line-endings _require_ one of the latter two encodings due to some SMTP limitation I do not know. It's certainly _possible_ to preserve them this way though. (And git send-email choose to use base64 for the second patch.) > Interestingly, even the author of those lines is sending patches with > Content-Transfer-Encoding: 7bit :-) see previous. (second patch contains bidi-marks and mixed line-endings, first neither) > LOL - so the majority on this ML is sending patches incorrectly? No, see second last. ___ 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] fatal: Resolve operation not in progress, we are not resuming.
Hi, On Wed, 02. Feb 16:02, Bryce Newman wrote: > Hi, > I am trying to apply this patch > https://patchwork.ffmpeg.org/project/ffmpeg/patch/d412c54e-2e51-4522-a8fb-32c5c6ca6...@gettyimages.com/. > I am able to `git apply` the patch locally and `make fate passes`, so I am > not sure what I need to do to get this patch to not throw warnings. > I have tried what is suggested in https://patchwork.ffmpeg.org/check/53886/. > > The results are… > > git am --show-current-patch=diff > fatal: Resolve operation not in progress, we are not resuming. > Probably your email client corrupted the patch when you pasted it in. Please use git send-email or attach the patch. Patchwork needs mime types text/x-diff or text/x-patch to process attachments. See also https://ffmpeg.org/developer.html#Submitting-patches As I understand you could also make a pull request to this repo: https://github.com/ffstaging/FFmpeg and your patch will get forwarded to the ffmpeg-devel mailing -- 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 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Oneric
> Sent: Wednesday, February 2, 2022 6:03 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
>
> It appears my previous mail has been interpreted as some sort of
> attack
> against you; this is not the case. I am sorry for creating such a
> misunderstanding.
Don't know who said that, but I don't feel attacked. It's about technical
details and opinions about it. All good.
> The mail was merely meant to clear up the misconception that it would
> be
> impossible to send mixed line-endings via mail due to some SMTP
> property
> using some illustrative examples from the current thread.
> (I have no idea how SMTP works in detail)
Where did you see such misconception? I think almost everybody knows
that this is doable over SMTP in some way, and there are in
fact many ways to do this, even when it would be as stupid like attaching
as zip archive.
It's never been a matter of SMTP. It's the GIT tooling in the context of
"patch-over-SMTP" transport and the way it is using plain-ascii-text
e-mails for this purpose. IMO, this is a design flaw or just a bug
when git-send-email and format-patch are creating output with transfer-encodings
7bit/8bit but mixed EOLs.
I suppose this is due to the tendency of GIT to consider text file basically
as files with lines of text where the line endings are exchangeable and
rather a platform detail than part of the text file's content.
And text files with mixed line endings are an accidental side effect of
multi-platform work and the endings can be re-unified at any time.
That's also the reason why format-patch cannot warn, because bazillions
of code files exist which have mixed EOLs (accidentally and exchangeable).
Yes, yes yes - don't need to respond that GIT can handle those cases
flawlessly and precisely when configured appropriately (and when not
using the e-mail features). That goes without saying.
I'm just speculating about history, why it might have happened that
it doesn't work flawlessly when using e-mail.
Via e-mail, it only works when using base64 encoding like you said,
but this had only been added at a later time and wasn't part of the
original functionality.
Further - I could find no evidence for your claims that base64 encoding
would be chosen automatically depending on the content, neither is it
on by default.
There's an 'auto' mode which chooses between 7bit, 8bit and quoted-printable,
but not base64, which always needs to be specified explicitly (or set in
.gitconfig).
This is the way it is documented and I'm seeing exactly that documented
behavior on both Linux and Windows when testing with a mocked smtp server.
You had contradicted my statement that it would be desirable that format-patch
would be able to do base64 encoding as well, saying that this would be the
task of a mail-client. This is not necessarily the case, though.
format-patch can generate patch e-mails with multipart-mime content, where
the patch content is created as an attachment mime part. format-patch does
that with a transfer-encoding of 8bit, but it can't do it with base64 encoding.
(I'm stripping the rest of your reply as it is all covered above already)
Regards,
softworkz
___
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/{ass, webvttdec}: fix handling of backslashes
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Wednesday, February 2, 2022 11:19 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Oneric
> > Sent: Wednesday, February 2, 2022 6:03 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}:
> fix
> > handling of backslashes
> >
> > It appears my previous mail has been interpreted as some sort of
> > attack
> > against you; this is not the case. I am sorry for creating such a
> > misunderstanding.
>
> Don't know who said that, but I don't feel attacked. It's about
> technical
> details and opinions about it. All good.
>
> > The mail was merely meant to clear up the misconception that it
> would
> > be
> > impossible to send mixed line-endings via mail due to some SMTP
> > property
> > using some illustrative examples from the current thread.
> > (I have no idea how SMTP works in detail)
>
> Where did you see such misconception? I think almost everybody knows
> that this is doable over SMTP in some way, and there are in
> fact many ways to do this, even when it would be as stupid like
> attaching
> as zip archive.
>
> It's never been a matter of SMTP. It's the GIT tooling in the context
> of
> "patch-over-SMTP" transport and the way it is using plain-ascii-text
> e-mails for this purpose. IMO, this is a design flaw or just a bug
> when git-send-email and format-patch are creating output with
> transfer-encodings
> 7bit/8bit but mixed EOLs.
>
> I suppose this is due to the tendency of GIT to consider text file
> basically
> as files with lines of text where the line endings are exchangeable
> and
> rather a platform detail than part of the text file's content.
> And text files with mixed line endings are an accidental side effect
> of
> multi-platform work and the endings can be re-unified at any time.
> That's also the reason why format-patch cannot warn, because
> bazillions
> of code files exist which have mixed EOLs (accidentally and
> exchangeable).
>
> Yes, yes yes - don't need to respond that GIT can handle those cases
> flawlessly and precisely when configured appropriately (and when not
> using the e-mail features). That goes without saying.
> I'm just speculating about history, why it might have happened that
> it doesn't work flawlessly when using e-mail.
>
> Via e-mail, it only works when using base64 encoding like you said,
> but this had only been added at a later time and wasn't part of the
> original functionality.
Haha, I almost forgot to get to my own point..
>From that situation above, I would conclude that at least at an earlier
time, the git developers (when asked about a case like the ffmpeg ref
files) might have argued that such files with mixed EOL where the
individual EOLs also form a relevant part of the
content - are not meant to be handled as text, but as binary
files (either) or at to use binary diffs when being send via e-mail.
.
sw
___
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] [PATCH] libavformat/mov: Expose Quicktime poster_time value as metadata TAG.
From: Bryce Chester Newman
I need the ability to derive the poster time found in the mvhd, so I can
use that value to create a thumbnail from ffmpeg. More details can be
found here
https://www.mail-archive.com/ffmpeg-user@ffmpeg.org/msg30003.html
Signed-off-by: Bryce Chester Newman
---
libavformat/mov: Expose Quicktime poster_time value as metadata TAG.
I need the ability to derive the poster time found in the mvhd, so I can
use that value to create a thumbnail from ffmpeg. More details can be
found here
https://www.mail-archive.com/ffmpeg-user@ffmpeg.org/msg30003.html
Signed-off-by: Bryce Chester Newman bryce.new...@gettyimages.com
Published-As:
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-21%2Fbrycechesternewman%2Fpatch-poster-time-tag-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg
pr-ffstaging-21/brycechesternewman/patch-poster-time-tag-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/21
libavformat/mov.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a80fcc1606..3d36f6563f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1487,6 +1487,7 @@ static int mov_read_mvhd(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
{
int i;
int64_t creation_time;
+int32_t poster_time;
int version = avio_r8(pb); /* version */
avio_rb24(pb); /* flags */
@@ -1525,12 +1526,21 @@ static int mov_read_mvhd(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
avio_rb32(pb); /* preview time */
avio_rb32(pb); /* preview duration */
-avio_rb32(pb); /* poster time */
+poster_time = avio_rb32(pb); /* poster time */
avio_rb32(pb); /* selection time */
avio_rb32(pb); /* selection duration */
avio_rb32(pb); /* current time */
avio_rb32(pb); /* next track ID */
+av_log(c->fc, AV_LOG_TRACE, "poster_time = %i, time_scale = %i\n",
poster_time, c->time_scale);
+if(poster_time && c->time_scale && c->time_scale > 0) {
+char buffer[32];
+float poster_time_location = (float)poster_time / c->time_scale;
+snprintf(buffer, sizeof(buffer), "%.2f", poster_time_location);
+/* This will appear as a TAG in the format section of FFProbe output
using -show_format */
+av_dict_set(&c->fc->metadata, "poster_time", buffer, 0);
+}
+
return 0;
}
base-commit: 2e82c610553efd69b4d9b6c359423a19c2868255
--
ffmpeg-codebot
___
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] http: Improve handling of Content-Range with Transfer-Encoding:chunked
From: Justin Ruggles
When Transfer-Encoding:chunked is used, the client must ignore a
Content-Length header, if present. However, it should not ignore a
Content-Range header, which also includes the full size of the
entity.
---
libavformat/http.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 8f39d11a88..c89f8a5517 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -132,6 +132,7 @@ typedef struct HTTPContext {
int64_t expires;
char *new_location;
AVDictionary *redirect_cache;
+uint64_t filesize_from_content_range;
} HTTPContext;
#define OFFSET(x) offsetof(HTTPContext, x)
@@ -839,7 +840,7 @@ static void parse_content_range(URLContext *h, const char
*p)
p += 6;
s->off = strtoull(p, NULL, 10);
if ((slash = strchr(p, '/')) && strlen(slash) > 0)
-s->filesize = strtoull(slash + 1, NULL, 10);
+s->filesize_from_content_range = strtoull(slash + 1, NULL, 10);
}
if (s->seekable == -1 && (!s->is_akamai || s->filesize != 2147483647))
h->is_streamed = 0; /* we _can_ in fact seek */
@@ -1341,6 +1342,7 @@ static int http_read_header(URLContext *h)
av_freep(&s->new_location);
s->expires = 0;
s->chunksize = UINT64_MAX;
+s->filesize_from_content_range = UINT64_MAX;
for (;;) {
if ((err = http_get_line(s, line, sizeof(line))) < 0)
@@ -1356,6 +1358,10 @@ static int http_read_header(URLContext *h)
s->line_count++;
}
+// filesize from Content-Range can always be used, even if using chunked
Transfer-Encoding
+if (s->filesize_from_content_range != UINT64_MAX)
+s->filesize = s->filesize_from_content_range;
+
if (s->seekable == -1 && s->is_mediagateway && s->filesize == 20)
h->is_streamed = 1; /* we can in fact _not_ seek */
--
2.34.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 2/2] http: Send a Range header even when the offset is 0
From: Justin Ruggles
Using Range allows for getting the full file size from the
Content-Range header in the response, even if the server sends
back the response using chunked Transfer-Encoding, which does not
allow using Content-Length.
---
libavformat/http.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index c89f8a5517..c79db955e8 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1469,10 +1469,10 @@ static int http_connect(URLContext *h, const char
*path, const char *local_path,
}
if (!has_header(s->headers, "\r\nAccept: "))
av_bprintf(&request, "Accept: */*\r\n");
-// Note: we send this on purpose even when s->off is 0 when we're probing,
+// Note: we send the Range header on purpose, even when we're probing,
// since it allows us to detect more reliably if a (non-conforming)
// server supports seeking by analysing the reply headers.
-if (!has_header(s->headers, "\r\nRange: ") && !post && (s->off > 0 ||
s->end_off || s->seekable == -1)) {
+if (!has_header(s->headers, "\r\nRange: ") && !post && (s->off > 0 ||
s->end_off || s->seekable != 0)) {
av_bprintf(&request, "Range: bytes=%"PRIu64"-", s->off);
if (s->end_off)
av_bprintf(&request, "%"PRId64, s->end_off - 1);
--
2.34.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] avformat/rtpdec_rfc4175: fix interlace format
In previous state, a new frame was allocated on each timestamp step,
i.e. each frame/field transition. However, for interlace, a new frame
should be allocated on 1st field, completed with the 2nd and finally
freed.
This commit fixes the frame allocation and the detection of missing RTP
markers.
Signed-off-by: Patrick Keroulas
---
libavformat/rtpdec_rfc4175.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
index 8e73c07838..83abe499f8 100644
--- a/libavformat/rtpdec_rfc4175.c
+++ b/libavformat/rtpdec_rfc4175.c
@@ -234,20 +234,21 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
uint8_t *dest;
if (*timestamp != data->timestamp) {
-if (data->frame) {
+if (data->frame && (!data->interlaced || data->field)) {
/*
- * if we're here, it means that two RTP packets didn't have the
- * same timestamp, which is a sign that they were packets from two
- * different frames, but we didn't get the flag RTP_FLAG_MARKER on
- * the first one of these frames (last packet of a frame).
- * Finalize the previous frame anyway by filling the AVPacket.
+ * if we're here, it means that we missed the cue to return
+ * the previous AVPacket, that cue being the RTP_FLAG_MARKER
+ * in the last packet of either the previous frame (progressive)
+ * or the previous second field (interlace). Let's finalize the
+ * previous frame (or pair of fields) anyway by filling the
AVPacket.
*/
av_log(ctx, AV_LOG_ERROR, "Missed previous RTP Marker\n");
missed_last_packet = 1;
rfc4175_finalize_packet(data, pkt, st->index);
}
-data->frame = av_malloc(data->frame_size);
+if (!data->frame)
+data->frame = av_malloc(data->frame_size);
data->timestamp = *timestamp;
--
2.25.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 74/80] avcodec/mpegvideo: Move decode_mb to H263DecContext
Only used by h263dec-based decoders; and only set by them
in their main threads.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263dec.c | 7 +--
libavcodec/h263dec.h | 2 ++
libavcodec/mpeg4videodec.c | 8
libavcodec/mpegvideo.h | 1 -
libavcodec/msmpeg4dec.c| 6 +++---
5 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 4327aec54d..91e95b910e 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -86,7 +86,7 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
ff_mpv_decode_init(m, avctx);
s->quant_precision = 5;
-s->decode_mb = ff_h263_decode_mb;
+h->decode_mb = ff_h263_decode_mb;
s->low_delay = 1;
/* select sub codec */
@@ -201,6 +201,9 @@ static int get_consumed_bytes(H263DecContext *h, int
buf_size)
static int decode_slice(MPVMainDecContext *m)
{
MPVDecContext *const s = &m->s;
+/* The following is only allowed because no h263dec based decoder
+ * uses slice threading. */
+H263DecContext *const h = (H263DecContext*)s;
const int part_mask = s->partitioned_frame
? (ER_AC_END | ER_AC_ERROR) : 0x7F;
const int mb_size = 16 >> s->avctx->lowres;
@@ -274,7 +277,7 @@ static int decode_slice(MPVMainDecContext *m)
get_bits_count(&s->gb), show_bits(&s->gb, 24));
ff_tlog(NULL, "Decoding MB at %dx%d\n", s->mb_x, s->mb_y);
-ret = s->decode_mb(s, s->block);
+ret = h->decode_mb(s, s->block);
if (s->pict_type != AV_PICTURE_TYPE_B)
ff_h263_update_motion_val(s);
diff --git a/libavcodec/h263dec.h b/libavcodec/h263dec.h
index b007372f64..13e097358f 100644
--- a/libavcodec/h263dec.h
+++ b/libavcodec/h263dec.h
@@ -42,6 +42,8 @@ extern const enum AVPixelFormat
ff_h263_hwaccel_pixfmt_list_420[];
typedef struct H263DecContext {
MPVMainDecContext m;
+
+int (*decode_mb)(MPVDecContext *s, int16_t block[12][64]); // used to
avoid a switch
} H263DecContext;
int ff_h263_decode_motion(MPVDecContext *s, int pred, int f_code);
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 854ccd5ade..7e3b672312 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -2946,9 +2946,9 @@ static int decode_vop_header(Mpeg4DecContext *ctx,
GetBitContext *gb,
s->partitioned_frame = s->data_partitioning && s->pict_type !=
AV_PICTURE_TYPE_B;
if (s->partitioned_frame)
-s->decode_mb = mpeg4_decode_partitioned_mb;
+h->decode_mb = mpeg4_decode_partitioned_mb;
else
-s->decode_mb = mpeg4_decode_mb;
+h->decode_mb = mpeg4_decode_mb;
time_incr = 0;
while (get_bits1(gb) != 0)
@@ -3242,7 +3242,7 @@ static int decode_studio_vop_header(Mpeg4DecContext *ctx,
GetBitContext *gb)
s->partitioned_frame = 0;
s->interlaced_dct = 0;
-s->decode_mb = mpeg4_decode_studio_mb;
+h->decode_mb = mpeg4_decode_studio_mb;
decode_smpte_tc(ctx, gb);
@@ -3653,7 +3653,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
s->h263_pred = 1;
s->low_delay = 0; /* default, might be overridden in the vol header during
header parsing */
-s->decode_mb = mpeg4_decode_mb;
+h->decode_mb = mpeg4_decode_mb;
ctx->time_increment_bits = 4; /* default value for broken headers */
avctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 2d5ee61a27..d0e4e8e9ff 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -424,7 +424,6 @@ typedef struct MPVContext {
int16_t (*block)[64]; ///< points to one of the following blocks
int16_t (*blocks)[12][64]; // for HQ mode we need to keep the best block
-int (*decode_mb)(struct MPVContext *s, int16_t block[12][64]); // used by
some codecs to avoid a switch()
#define SLICE_OK 0
#define SLICE_ERROR -1
diff --git a/libavcodec/msmpeg4dec.c b/libavcodec/msmpeg4dec.c
index b1f4df7aa9..c0d5d60cc6 100644
--- a/libavcodec/msmpeg4dec.c
+++ b/libavcodec/msmpeg4dec.c
@@ -382,15 +382,15 @@ av_cold int ff_msmpeg4_decode_init(AVCodecContext *avctx)
switch(s->msmpeg4_version){
case 1:
case 2:
-s->decode_mb= msmpeg4v12_decode_mb;
+h->decode_mb = msmpeg4v12_decode_mb;
break;
case 3:
case 4:
-s->decode_mb= msmpeg4v34_decode_mb;
+h->decode_mb = msmpeg4v34_decode_mb;
break;
case 5:
if (CONFIG_WMV2_DECODER)
-s->decode_mb= ff_wmv2_decode_mb;
+h->decode_mb = ff_wmv2_decode_mb;
case 6:
//FIXME + TODO VC1 decode mb
break;
--
2.32.0
___
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
[FFmpeg-devel] [PATCH 73/80] avcodec/h263dec.h: Add H263DecContext
This is in preparation for moving fields only used by h263dec-based
decoders from MPVContext.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dxva2_vc1.c | 16 +--
libavcodec/flvdec.c| 6 ++--
libavcodec/flvdec.h| 4 +--
libavcodec/h263dec.c | 34 ---
libavcodec/h263dec.h | 10 +--
libavcodec/intelh263dec.c | 8 +++---
libavcodec/ituh263dec.c| 10 +++
libavcodec/mpeg4video_parser.c | 6 ++--
libavcodec/mpeg4videodec.c | 51 +++---
libavcodec/mpeg4videodec.h | 3 +-
libavcodec/msmpeg4dec.c| 21 +++---
libavcodec/msmpeg4dec.h| 5 ++--
libavcodec/mss2.c | 8 +++---
libavcodec/nvdec_mpeg4.c | 3 +-
libavcodec/nvdec_vc1.c | 4 +--
libavcodec/rv10.c | 10 ---
libavcodec/vaapi_mpeg4.c | 2 +-
libavcodec/vaapi_vc1.c | 50 -
libavcodec/vc1.c | 24
libavcodec/vc1.h | 4 +--
libavcodec/vc1_block.c | 40 +-
libavcodec/vc1_loopfilter.c| 28 +--
libavcodec/vc1_mc.c| 14 +-
libavcodec/vc1_parser.c| 8 +++---
libavcodec/vc1_pred.c | 22 +++
libavcodec/vc1dec.c| 16 +--
libavcodec/vdpau_mpeg4.c | 2 +-
libavcodec/vdpau_vc1.c | 6 ++--
libavcodec/wmv2dec.c | 28 +--
libavcodec/wmv2dec.h | 5 ++--
30 files changed, 234 insertions(+), 214 deletions(-)
diff --git a/libavcodec/dxva2_vc1.c b/libavcodec/dxva2_vc1.c
index d901f023df..e30b432fc6 100644
--- a/libavcodec/dxva2_vc1.c
+++ b/libavcodec/dxva2_vc1.c
@@ -41,7 +41,7 @@ static void fill_picture_parameters(AVCodecContext *avctx,
AVDXVAContext *ctx, const VC1Context *v,
DXVA_PictureParameters *pp)
{
-const MPVDecContext *const s = &v->s.s;
+const MPVDecContext *const s = &v->h.m.s;
const Picture *current_picture = s->current_picture_ptr;
int intcomp = 0;
@@ -164,7 +164,7 @@ static void fill_slice(AVCodecContext *avctx,
DXVA_SliceInfo *slice,
unsigned position, unsigned size)
{
const VC1Context *v = avctx->priv_data;
-const MPVDecContext *const s = &v->s.s;
+const MPVDecContext *const s = &v->h.m.s;
memset(slice, 0, sizeof(*slice));
slice->wHorizontalPosition = 0;
@@ -186,7 +186,7 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
{
const VC1Context *v = avctx->priv_data;
AVDXVAContext *ctx = DXVA_CONTEXT(avctx);
-const MPVDecContext *const s = &v->s.s;
+const MPVDecContext *const s = &v->h.m.s;
struct dxva2_picture_context *ctx_pic =
s->current_picture_ptr->hwaccel_picture_private;
static const uint8_t start_code[] = { 0, 0, 1, 0x0d };
@@ -313,7 +313,7 @@ static int dxva2_vc1_start_frame(AVCodecContext *avctx,
{
const VC1Context *v = avctx->priv_data;
AVDXVAContext *ctx = DXVA_CONTEXT(avctx);
-struct dxva2_picture_context *ctx_pic =
v->s.s.current_picture_ptr->hwaccel_picture_private;
+struct dxva2_picture_context *ctx_pic =
v->h.m.s.current_picture_ptr->hwaccel_picture_private;
if (!DXVA_CONTEXT_VALID(avctx, ctx))
return -1;
@@ -332,7 +332,7 @@ static int dxva2_vc1_decode_slice(AVCodecContext *avctx,
uint32_t size)
{
const VC1Context *v = avctx->priv_data;
-const Picture *current_picture = v->s.s.current_picture_ptr;
+const Picture *current_picture = v->h.m.s.current_picture_ptr;
struct dxva2_picture_context *ctx_pic =
current_picture->hwaccel_picture_private;
unsigned position;
@@ -360,18 +360,18 @@ static int dxva2_vc1_decode_slice(AVCodecContext *avctx,
static int dxva2_vc1_end_frame(AVCodecContext *avctx)
{
VC1Context *v = avctx->priv_data;
-struct dxva2_picture_context *ctx_pic =
v->s.s.current_picture_ptr->hwaccel_picture_private;
+struct dxva2_picture_context *ctx_pic =
v->h.m.s.current_picture_ptr->hwaccel_picture_private;
int ret;
if (ctx_pic->slice_count <= 0 || ctx_pic->bitstream_size <= 0)
return -1;
-ret = ff_dxva2_common_end_frame(avctx, v->s.s.current_picture_ptr->f,
+ret = ff_dxva2_common_end_frame(avctx, v->h.m.s.current_picture_ptr->f,
&ctx_pic->pp, sizeof(ctx_pic->pp),
NULL, 0,
commit_bitstream_and_slice_buffer);
if (!ret)
-ff_mpeg_draw_horiz_band(&v->s.s, 0, avctx->height);
+ff_mpeg_draw_horiz_band(&v->h.m.s, 0, avctx->height);
return ret;
}
diff --git a/libavcodec/flvdec.c b/libavcodec/flvdec.c
index 469a8ceae9..3c14f2c54c 100644
--- a/libavcodec/flvdec.c
+++ b/libavcodec/flvdec.c
@@ -26,9 +26,9 @@
#
[FFmpeg-devel] [PATCH 75/80] avcodec/mpegvideo: Move h263_long_vectors to H263DecContext
Signed-off-by: Andreas Rheinhardt
---
libavcodec/flvdec.c | 2 +-
libavcodec/h263dec.h | 1 +
libavcodec/intelh263dec.c | 2 +-
libavcodec/ituh263dec.c | 9 ++---
libavcodec/mpegvideo.h| 1 -
libavcodec/rv10.c | 2 +-
6 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/libavcodec/flvdec.c b/libavcodec/flvdec.c
index 3c14f2c54c..8ff4c03100 100644
--- a/libavcodec/flvdec.c
+++ b/libavcodec/flvdec.c
@@ -92,7 +92,7 @@ int ff_flv_decode_picture_header(H263DecContext *h)
s->h263_plus = 0;
-s->h263_long_vectors = 0;
+h->long_vectors = 0;
/* PEI */
if (skip_1stop_8data_bits(&s->gb) < 0)
diff --git a/libavcodec/h263dec.h b/libavcodec/h263dec.h
index 13e097358f..9c4c26242c 100644
--- a/libavcodec/h263dec.h
+++ b/libavcodec/h263dec.h
@@ -44,6 +44,7 @@ typedef struct H263DecContext {
MPVMainDecContext m;
int (*decode_mb)(MPVDecContext *s, int16_t block[12][64]); // used to
avoid a switch
+int long_vectors; ///< use horrible H.263v1 long vector mode
} H263DecContext;
int ff_h263_decode_motion(MPVDecContext *s, int pred, int f_code);
diff --git a/libavcodec/intelh263dec.c b/libavcodec/intelh263dec.c
index deed9152ea..f621c9686c 100644
--- a/libavcodec/intelh263dec.c
+++ b/libavcodec/intelh263dec.c
@@ -62,7 +62,7 @@ int ff_intel_h263_decode_picture_header(H263DecContext *h)
s->pict_type = AV_PICTURE_TYPE_I + get_bits1(&s->gb);
-s->h263_long_vectors = get_bits1(&s->gb);
+h->long_vectors = get_bits1(&s->gb);
if (get_bits1(&s->gb) != 0) {
av_log(s->avctx, AV_LOG_ERROR, "SAC not supported\n");
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 9e92ed94ce..299a668290 100644
--- a/libavcodec/ituh263dec.c
+++ b/libavcodec/ituh263dec.c
@@ -82,7 +82,7 @@ void ff_h263_show_pict_info(H263DecContext *h)
s->gb.size_in_bits, 1-s->no_rounding,
s->obmc ? " AP" : "",
s->umvplus ? " UMV" : "",
- s->h263_long_vectors ? " LONG" : "",
+ h->long_vectors ? " LONG" : "",
s->h263_plus ? " +" : "",
s->h263_aic ? " AIC" : "",
s->alt_inter_vlc ? " AIV" : "",
@@ -272,6 +272,9 @@ int ff_h263_resync(MPVMainDecContext *m)
int ff_h263_decode_motion(MPVDecContext *s, int pred, int f_code)
{
+/* The following is only allowed because no h263dec-based
+ * decoder uses slice-threading. */
+const H263DecContext *const h = (H263DecContext*)s;
int code, val, sign, shift;
code = get_vlc2(&s->gb, ff_h263_mv_vlc.table, H263_MV_VLC_BITS, 2);
@@ -293,7 +296,7 @@ int ff_h263_decode_motion(MPVDecContext *s, int pred, int
f_code)
val += pred;
/* modulo decoding */
-if (!s->h263_long_vectors) {
+if (!h->long_vectors) {
val = sign_extend(val, 5 + f_code);
} else {
/* horrible H.263 long vector mode */
@@ -1150,7 +1153,7 @@ int ff_h263_decode_picture_header(H263DecContext *h)
s->pict_type = AV_PICTURE_TYPE_I + get_bits1(&s->gb);
-s->h263_long_vectors = get_bits1(&s->gb);
+h->long_vectors = get_bits1(&s->gb);
if (get_bits1(&s->gb) != 0) {
av_log(s->avctx, AV_LOG_ERROR, "H.263 SAC not supported\n");
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index d0e4e8e9ff..0e26bed7fd 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -177,7 +177,6 @@ typedef struct MPVContext {
/* motion compensation */
int unrestricted_mv;///< mv can point outside of the coded picture
-int h263_long_vectors; ///< use horrible H.263v1 long vector mode
BlockDSPContext bdsp;
FDCTDSPContext fdsp;
diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 1fbd99a965..e1379b634c 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -390,7 +390,7 @@ static av_cold int rv10_decode_init(AVCodecContext *avctx)
rv->orig_height =
s->height = avctx->coded_height;
-s->h263_long_vectors = ((uint8_t *) avctx->extradata)[3] & 1;
+h->long_vectors = avctx->extradata[3] & 1;
rv->sub_id = AV_RB32((uint8_t *) avctx->extradata + 4);
major_ver = RV_GET_MAJOR_VER(rv->sub_id);
--
2.32.0
___
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 76/80] avcodec/mpegvideo: Move ehc_mode to H263DecContext
Signed-off-by: Andreas Rheinhardt
---
libavcodec/flvdec.c | 2 +-
libavcodec/h263dec.c| 2 +-
libavcodec/h263dec.h| 1 +
libavcodec/ituh263dec.c | 2 +-
libavcodec/mpegvideo.h | 1 -
5 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/flvdec.c b/libavcodec/flvdec.c
index 8ff4c03100..d33cc11b27 100644
--- a/libavcodec/flvdec.c
+++ b/libavcodec/flvdec.c
@@ -100,7 +100,7 @@ int ff_flv_decode_picture_header(H263DecContext *h)
s->f_code = 1;
-if (s->ehc_mode)
+if (h->ehc_mode)
s->avctx->sample_aspect_ratio= (AVRational){1,2};
if (s->avctx->debug & FF_DEBUG_PICT_INFO) {
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 91e95b910e..db03e04143 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -139,7 +139,7 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
if (avctx->codec_tag == AV_RL32("L263") || avctx->codec_tag ==
AV_RL32("S263"))
if (avctx->extradata_size == 56 && avctx->extradata[0] == 1)
-s->ehc_mode = 1;
+h->ehc_mode = 1;
/* for H.263, we allocate the images after having read the header */
if (avctx->codec->id != AV_CODEC_ID_H263 &&
diff --git a/libavcodec/h263dec.h b/libavcodec/h263dec.h
index 9c4c26242c..e090f4b39b 100644
--- a/libavcodec/h263dec.h
+++ b/libavcodec/h263dec.h
@@ -45,6 +45,7 @@ typedef struct H263DecContext {
int (*decode_mb)(MPVDecContext *s, int16_t block[12][64]); // used to
avoid a switch
int long_vectors; ///< use horrible H.263v1 long vector mode
+int ehc_mode;
} H263DecContext;
int ff_h263_decode_motion(MPVDecContext *s, int pred, int f_code);
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 299a668290..8467746a0e 100644
--- a/libavcodec/ituh263dec.c
+++ b/libavcodec/ituh263dec.c
@@ -1258,7 +1258,7 @@ int ff_h263_decode_picture_header(H263DecContext *h)
height = ff_h263_format[format][1];
s->avctx->sample_aspect_ratio= (AVRational){12,11};
}
-s->avctx->sample_aspect_ratio.den <<= s->ehc_mode;
+s->avctx->sample_aspect_ratio.den <<= h->ehc_mode;
if ((width == 0) || (height == 0))
return -1;
s->width = width;
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 0e26bed7fd..7be9b889ea 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -302,7 +302,6 @@ typedef struct MPVContext {
int prev_mb_info, last_mb_info;
uint8_t *mb_info_ptr;
int mb_info_size;
-int ehc_mode;
/* H.263+ specific */
int umvplus;///< == H.263+ && unrestricted_mv
--
2.32.0
___
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 77/80] avcodec/mpegvideo: Move pb_frame to H263DecContext
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263dec.h | 1 +
libavcodec/intelh263dec.c | 6 +++---
libavcodec/ituh263dec.c | 21 -
libavcodec/mpegvideo.h| 1 -
4 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/libavcodec/h263dec.h b/libavcodec/h263dec.h
index e090f4b39b..7eebffc91c 100644
--- a/libavcodec/h263dec.h
+++ b/libavcodec/h263dec.h
@@ -44,6 +44,7 @@ typedef struct H263DecContext {
MPVMainDecContext m;
int (*decode_mb)(MPVDecContext *s, int16_t block[12][64]); // used to
avoid a switch
+int pb_frame; ///< PB-frame mode (0 = none, 1 = base, 2 =
improved)
int long_vectors; ///< use horrible H.263v1 long vector mode
int ehc_mode;
} H263DecContext;
diff --git a/libavcodec/intelh263dec.c b/libavcodec/intelh263dec.c
index f621c9686c..a5cd6dd1de 100644
--- a/libavcodec/intelh263dec.c
+++ b/libavcodec/intelh263dec.c
@@ -69,7 +69,7 @@ int ff_intel_h263_decode_picture_header(H263DecContext *h)
return -1; /* SAC: off */
}
s->obmc= get_bits1(&s->gb);
-s->pb_frame = get_bits1(&s->gb);
+h->pb_frame = get_bits1(&s->gb);
if (format < 6) {
s->width = ff_h263_format[format][0];
@@ -88,7 +88,7 @@ int ff_intel_h263_decode_picture_header(H263DecContext *h)
if(get_bits1(&s->gb))
av_log(s->avctx, AV_LOG_ERROR, "Bad value for reserved field\n");
if(get_bits1(&s->gb))
-s->pb_frame = 2;
+h->pb_frame = 2;
if(get_bits(&s->gb, 5))
av_log(s->avctx, AV_LOG_ERROR, "Bad value for reserved field\n");
if(get_bits(&s->gb, 5) != 1)
@@ -112,7 +112,7 @@ int ff_intel_h263_decode_picture_header(H263DecContext *h)
s->chroma_qscale= s->qscale = get_bits(&s->gb, 5);
skip_bits1(&s->gb); /* Continuous Presence Multipoint mode: off */
-if(s->pb_frame){
+if (h->pb_frame) {
skip_bits(&s->gb, 3); //temporal reference for B-frame
skip_bits(&s->gb, 2); //dbquant
}
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 8467746a0e..15365afebc 100644
--- a/libavcodec/ituh263dec.c
+++ b/libavcodec/ituh263dec.c
@@ -792,6 +792,9 @@ static int set_direct_mv(MPVDecContext *s)
int ff_h263_decode_mb(MPVDecContext *s,
int16_t block[6][64])
{
+/* The following is only allowed because no h263dec-based
+ * decoder uses slice-threading. */
+const H263DecContext *const h = (H263DecContext*)s;
int cbpc, cbpy, i, cbp, pred_x, pred_y, mx, my, dquant;
int16_t *mot_val;
const int xy= s->mb_x + s->mb_y * s->mb_stride;
@@ -827,8 +830,8 @@ int ff_h263_decode_mb(MPVDecContext *s,
s->mb_intra = ((cbpc & 4) != 0);
if (s->mb_intra) goto intra;
-if(s->pb_frame && get_bits1(&s->gb))
-pb_mv_count = h263_get_modb(&s->gb, s->pb_frame, &cbpb);
+if (h->pb_frame && get_bits1(&s->gb))
+pb_mv_count = h263_get_modb(&s->gb, h->pb_frame, &cbpb);
cbpy = get_vlc2(&s->gb, ff_h263_cbpy_vlc.table, CBPY_VLC_BITS, 1);
if (cbpy < 0) {
@@ -1037,8 +1040,8 @@ intra:
}else
s->ac_pred = 0;
-if(s->pb_frame && get_bits1(&s->gb))
-pb_mv_count = h263_get_modb(&s->gb, s->pb_frame, &cbpb);
+if (h->pb_frame && get_bits1(&s->gb))
+pb_mv_count = h263_get_modb(&s->gb, h->pb_frame, &cbpb);
cbpy = get_vlc2(&s->gb, ff_h263_cbpy_vlc.table, CBPY_VLC_BITS, 1);
if(cbpy<0){
av_log(s->avctx, AV_LOG_ERROR, "I cbpy damaged at %d %d\n",
s->mb_x, s->mb_y);
@@ -1049,7 +1052,7 @@ intra:
h263_decode_dquant(s);
}
-pb_mv_count += !!s->pb_frame;
+pb_mv_count += !!h->pb_frame;
}
while(pb_mv_count--){
@@ -1064,7 +1067,7 @@ intra:
cbp+=cbp;
}
-if(s->pb_frame && h263_skip_b_part(s, cbpb) < 0)
+if (h->pb_frame && h263_skip_b_part(s, cbpb) < 0)
return -1;
if(s->obmc && !s->mb_intra){
if(s->pict_type == AV_PICTURE_TYPE_P && s->mb_x+1mb_width &&
s->mb_num_left != 1)
@@ -1161,7 +1164,7 @@ int ff_h263_decode_picture_header(H263DecContext *h)
}
s->obmc= get_bits1(&s->gb); /* Advanced prediction mode */
-s->pb_frame = get_bits1(&s->gb);
+h->pb_frame = get_bits1(&s->gb);
s->chroma_qscale= s->qscale = get_bits(&s->gb, 5);
skip_bits1(&s->gb); /* Continuous Presence Multipoint mode: off */
@@ -1217,7 +1220,7 @@ int ff_h263_decode_picture_header(H263DecContext *h)
switch(s->pict_type){
case 0: s->pict_type= AV_PICTURE_TYPE_I;break;
case 1: s->pict_type= AV_PICTURE_TYPE_P;break;
-case 2: s->pict_type= AV_PICTURE_TYPE_P;s->pb_frame = 3;break;
+case 2: s->pict_type= AV_PICTURE_TYPE_P; h->pb_frame = 3;break;
case 3: s->pict_type= AV_PICTURE_TYPE_B;break;
case 7: s->pict_type= AV_PICTURE_TYPE_I;break; //ZYGO
default:
@@ -
[FFmpeg-devel] [PATCH 79/80] avcodec/mpegvideo: Move custom_pcf to H263DecContext
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263dec.h| 1 +
libavcodec/ituh263dec.c | 9 -
libavcodec/mpegvideo.h | 1 -
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavcodec/h263dec.h b/libavcodec/h263dec.h
index 04c238d90a..539f2df01a 100644
--- a/libavcodec/h263dec.h
+++ b/libavcodec/h263dec.h
@@ -47,6 +47,7 @@ typedef struct H263DecContext {
int pb_frame; ///< PB-frame mode (0 = none, 1 = base, 2 =
improved)
int long_vectors; ///< use horrible H.263v1 long vector mode
int ehc_mode;
+int custom_pcf;
/* divx specific, used to workaround (many) bugs in divx5 */
int divx_packed;
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 15365afebc..0ce0b1c795 100644
--- a/libavcodec/ituh263dec.c
+++ b/libavcodec/ituh263dec.c
@@ -1184,7 +1184,7 @@ int ff_h263_decode_picture_header(H263DecContext *h)
/* OPPTYPE */
format = get_bits(&s->gb, 3);
ff_dlog(s->avctx, "ufep=1, format: %d\n", format);
-s->custom_pcf= get_bits1(&s->gb);
+h->custom_pcf = get_bits1(&s->gb);
s->umvplus = get_bits1(&s->gb); /* Unrestricted Motion Vector */
if (get_bits1(&s->gb) != 0) {
av_log(s->avctx, AV_LOG_ERROR, "Syntax-based Arithmetic Coding
(SAC) not supported\n");
@@ -1267,7 +1267,7 @@ int ff_h263_decode_picture_header(H263DecContext *h)
s->width = width;
s->height = height;
-if(s->custom_pcf){
+if (h->custom_pcf) {
int gcd;
s->avctx->framerate.num = 180;
s->avctx->framerate.den = 1000 + get_bits1(&s->gb);
@@ -1284,9 +1284,8 @@ int ff_h263_decode_picture_header(H263DecContext *h)
}
}
-if(s->custom_pcf){
+if (h->custom_pcf)
skip_bits(&s->gb, 2); //extended Temporal reference
-}
if (ufep) {
if (s->umvplus) {
@@ -1326,7 +1325,7 @@ int ff_h263_decode_picture_header(H263DecContext *h)
if (h->pb_frame) {
skip_bits(&s->gb, 3); /* Temporal reference for B-pictures */
-if (s->custom_pcf)
+if (h->custom_pcf)
skip_bits(&s->gb, 2); //extended Temporal reference
skip_bits(&s->gb, 2); /* Quantization information for B-pictures */
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 2b5267f1c3..1be77bc83b 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -309,7 +309,6 @@ typedef struct MPVContext {
int alt_inter_vlc; ///< alternative inter vlc
int modified_quant;
int loop_filter;
-int custom_pcf;
/* MPEG-4 specific */
int studio_profile;
--
2.32.0
___
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 80/80] avcodec/mpegvideo_enc: Remove redundant unref+ref
Setting current_picture will already be done in frame_start(). Signed-off-by: Andreas Rheinhardt --- libavcodec/mpegvideo_enc.c | 5 - 1 file changed, 5 deletions(-) diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c index ddfd123c46..9c68983205 100644 --- a/libavcodec/mpegvideo_enc.c +++ b/libavcodec/mpegvideo_enc.c @@ -1598,11 +1598,6 @@ no_output_pic: s->new_picture->data[i] += INPLACE_OFFSET; } } -ff_mpeg_unref_picture(s->avctx, &s->current_picture); -if ((ret = ff_mpeg_ref_picture(s->avctx, &s->current_picture, - s->current_picture_ptr)) < 0) -return ret; - s->picture_number = s->new_picture->display_picture_number; } return 0; -- 2.32.0 ___ 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 78/80] avcodec/mpegvideo: Move packed-b-frames stuff to H263DecContext
It is only used by the MPEG-4 decoder, yet it is used in
the common H.263-code (i.e. in libavcodec/h263dec.c) and
can therefore not be put in Mpeg4DecContext. Yet moving
it to H263DecContext is possible.
Given that this is nevertheless an MPEG-4 only field,
it is kept in sync in the MPEG-4-decoder's update_thread_context
and not in a (currently inexisting) update_thread_context for
H.263 decoders.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263dec.c | 27 ---
libavcodec/h263dec.h | 6
libavcodec/mpeg4videodec.c | 70 +++---
libavcodec/mpegvideo.c | 5 ---
libavcodec/mpegvideo.h | 6
libavcodec/mpegvideo_dec.c | 24 -
libavcodec/nvdec_mpeg4.c | 2 +-
7 files changed, 73 insertions(+), 67 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index db03e04143..3b0ebbdf9b 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -160,9 +160,12 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
av_cold int ff_h263_decode_end(AVCodecContext *avctx)
{
-MPVMainDecContext *const s = avctx->priv_data;
+H263DecContext *const h263 = avctx->priv_data;
-ff_mpv_common_end(s);
+av_freep(&h263->bitstream_buffer);
+h263->allocated_bitstream_buffer_size = 0;
+
+ff_mpv_common_end(&h263->m);
return 0;
}
@@ -174,7 +177,7 @@ static int get_consumed_bytes(H263DecContext *h, int
buf_size)
MPVDecContext *const s = &h->m.s;
int pos = (get_bits_count(&s->gb) + 7) >> 3;
-if (s->divx_packed || s->avctx->hwaccel) {
+if (h->divx_packed || s->avctx->hwaccel) {
/* We would have to scan through the whole buf to handle the weird
* reordering ... */
return buf_size;
@@ -481,26 +484,26 @@ int ff_h263_decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
#endif
retry:
-if (s->divx_packed && s->bitstream_buffer_size) {
+if (h->divx_packed && h->bitstream_buffer_size) {
int i;
for(i=0; i < buf_size-3; i++) {
if (buf[i]==0 && buf[i+1]==0 && buf[i+2]==1) {
if (buf[i+3]==0xB0) {
av_log(s->avctx, AV_LOG_WARNING, "Discarding excessive
bitstream in packed xvid\n");
-s->bitstream_buffer_size = 0;
+h->bitstream_buffer_size = 0;
}
break;
}
}
}
-if (s->bitstream_buffer_size && (s->divx_packed || buf_size <=
MAX_NVOP_SIZE)) // divx 5.01+/xvid frame reorder
-ret = init_get_bits8(&s->gb, s->bitstream_buffer,
- s->bitstream_buffer_size);
+if (h->bitstream_buffer_size && (h->divx_packed || buf_size <=
MAX_NVOP_SIZE)) // divx 5.01+/xvid frame reorder
+ret = init_get_bits8(&s->gb, h->bitstream_buffer,
+ h->bitstream_buffer_size);
else
ret = init_get_bits8(&s->gb, buf, buf_size);
-s->bitstream_buffer_size = 0;
+h->bitstream_buffer_size = 0;
if (ret < 0)
return ret;
@@ -625,7 +628,7 @@ retry:
if ((ret = ff_mpv_frame_start(m, avctx)) < 0)
return ret;
-if (!s->divx_packed && !avctx->hwaccel)
+if (!h->divx_packed && !avctx->hwaccel)
ff_thread_finish_setup(avctx);
if (avctx->hwaccel) {
@@ -679,7 +682,7 @@ retry:
ff_msmpeg4_decode_ext_header(h, buf_size) < 0)
s->er.error_status_table[s->mb_num - 1] = ER_MB_ERROR;
-av_assert1(s->bitstream_buffer_size == 0);
+av_assert1(h->bitstream_buffer_size == 0);
frame_end:
if (!s->studio_profile)
ff_er_frame_end(&s->er);
@@ -695,7 +698,7 @@ frame_end:
if (CONFIG_MPEG4_DECODER && avctx->codec_id == AV_CODEC_ID_MPEG4)
ff_mpeg4_frame_end(avctx, buf, buf_size);
-if (!s->divx_packed && avctx->hwaccel)
+if (!h->divx_packed && avctx->hwaccel)
ff_thread_finish_setup(avctx);
av_assert1(s->current_picture.f->pict_type ==
s->current_picture_ptr->f->pict_type);
diff --git a/libavcodec/h263dec.h b/libavcodec/h263dec.h
index 7eebffc91c..04c238d90a 100644
--- a/libavcodec/h263dec.h
+++ b/libavcodec/h263dec.h
@@ -47,6 +47,12 @@ typedef struct H263DecContext {
int pb_frame; ///< PB-frame mode (0 = none, 1 = base, 2 =
improved)
int long_vectors; ///< use horrible H.263v1 long vector mode
int ehc_mode;
+
+/* divx specific, used to workaround (many) bugs in divx5 */
+int divx_packed;
+uint8_t *bitstream_buffer; //Divx 5.01 puts several frames in a single
one, this is used to reorder them
+int bitstream_buffer_size;
+unsigned int allocated_bitstream_buffer_size;
} H263DecContext;
int ff_h263_decode_motion(MPVDecContext *s, int pred, int f_code);
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 7e3b672312..2d1463d564 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -2774,7 +2774,7 @@ static i
Re: [FFmpeg-devel] [PATCH 1/2] http: Improve handling of Content-Range with Transfer-Encoding:chunked
On Wed, Feb 2, 2022 at 3:50 PM Vittorio Giovara
wrote:
> From: Justin Ruggles
>
> When Transfer-Encoding:chunked is used, the client must ignore a
> Content-Length header, if present. However, it should not ignore a
> Content-Range header, which also includes the full size of the
> entity.
> ---
> libavformat/http.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 8f39d11a88..c89f8a5517 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -132,6 +132,7 @@ typedef struct HTTPContext {
> int64_t expires;
> char *new_location;
> AVDictionary *redirect_cache;
> +uint64_t filesize_from_content_range;
> } HTTPContext;
>
> #define OFFSET(x) offsetof(HTTPContext, x)
> @@ -839,7 +840,7 @@ static void parse_content_range(URLContext *h, const
> char *p)
> p += 6;
> s->off = strtoull(p, NULL, 10);
> if ((slash = strchr(p, '/')) && strlen(slash) > 0)
> -s->filesize = strtoull(slash + 1, NULL, 10);
> +s->filesize_from_content_range = strtoull(slash + 1, NULL,
> 10);
>
The size part of the range header is optional, and can be '*' as well.
See also
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211005233244.37582-1-ffm...@tmm1.net/
> }
> if (s->seekable == -1 && (!s->is_akamai || s->filesize != 2147483647))
> h->is_streamed = 0; /* we _can_ in fact seek */
> @@ -1341,6 +1342,7 @@ static int http_read_header(URLContext *h)
> av_freep(&s->new_location);
> s->expires = 0;
> s->chunksize = UINT64_MAX;
> +s->filesize_from_content_range = UINT64_MAX;
>
> for (;;) {
> if ((err = http_get_line(s, line, sizeof(line))) < 0)
> @@ -1356,6 +1358,10 @@ static int http_read_header(URLContext *h)
> s->line_count++;
> }
>
> +// filesize from Content-Range can always be used, even if using
> chunked Transfer-Encoding
> +if (s->filesize_from_content_range != UINT64_MAX)
> +s->filesize = s->filesize_from_content_range;
> +
> if (s->seekable == -1 && s->is_mediagateway && s->filesize ==
> 20)
> h->is_streamed = 1; /* we can in fact _not_ seek */
>
> --
> 2.34.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".
Re: [FFmpeg-devel] [PATCH] avformat/imf_cpl: do not use filesize when reading XML file
Works for me.
There are several other IMF-related patches waiting, some of them
rather trivial. Should they be combined and/or merged together?
On Mon, Jan 31, 2022 at 3:13 PM Marton Balint wrote:
>
> Similar to the earlier patch applied to imfdec.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/imf_cpl.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
> index f2ad9c05d6..102a6b4549 100644
> --- a/libavformat/imf_cpl.c
> +++ b/libavformat/imf_cpl.c
> @@ -797,13 +797,11 @@ int ff_imf_parse_cpl(AVIOContext *in, FFIMFCPL **cpl)
> AVBPrint buf;
> xmlDoc *doc = NULL;
> int ret = 0;
> -int64_t filesize = 0;
>
> -filesize = avio_size(in);
> -filesize = filesize > 0 ? filesize : 8192;
> -av_bprint_init(&buf, filesize + 1, AV_BPRINT_SIZE_UNLIMITED);
> -ret = avio_read_to_bprint(in, &buf, UINT_MAX - 1);
> -if (ret < 0 || !avio_feof(in) || buf.len == 0) {
> +av_bprint_init(&buf, 0, INT_MAX); // xmlReadMemory uses integer length
> +
> +ret = avio_read_to_bprint(in, &buf, SIZE_MAX);
> +if (ret < 0 || !avio_feof(in)) {
> av_log(NULL, AV_LOG_ERROR, "Cannot read IMF CPL\n");
> if (ret == 0)
> ret = AVERROR_INVALIDDATA;
> @@ -812,8 +810,7 @@ int ff_imf_parse_cpl(AVIOContext *in, FFIMFCPL **cpl)
>
> LIBXML_TEST_VERSION
>
> -filesize = buf.len;
> -doc = xmlReadMemory(buf.str, filesize, NULL, NULL, 0);
> +doc = xmlReadMemory(buf.str, buf.len, NULL, NULL, 0);
> if (!doc) {
> av_log(NULL,
> AV_LOG_ERROR,
> --
> 2.31.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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
On Wed, Feb 02, 2022 at 22:44:18 +, Soft Works wrote: > > Sent: Wednesday, February 2, 2022 11:19 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > > > [claims about git and smtp: part 1] > > > > [claims about git and smtp: part 2] > None of this relates to the topic of the patches, which is backslash-escaping in ASS and converting BIDI-marks from WebVTT. As written before, I see no point in advancing this offtopic talk; please actually discuss the content of the patches in this thread. If you are convinced that the reference files should be treated as binary, then submit a suitable gitattributes patch to the list and discuss it with whom it may interest. I’ll ignore all further offtopic messages here. ___ 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 v3 1/4] avformat/imf: open resources only when first needed
From: Pierre-Anthony Lemieux
IMF CPLs can reference thousands of files, which can result in system limits
for the number of open files to be exceeded. The following patch opens and
closes files as needed.
Addresses https://trac.ffmpeg.org/ticket/9623
---
libavformat/imfdec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index d67c9b8898..e6a1020ecc 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -103,10 +103,11 @@ typedef struct IMFVirtualTrackPlaybackCtx {
int32_t index; /**< Track index in
playlist */
AVRational current_timestamp; /**< Current temporal
position */
AVRational duration; /**< Overall duration */
-uint32_t resource_count; /**< Number of resources */
+uint32_t resource_count; /**< Number of resources
(<= INT32_MAX) */
unsigned int resources_alloc_sz; /**< Size of the buffer
holding the resource */
IMFVirtualTrackResourcePlaybackCtx *resources; /**< Buffer holding the
resources */
-uint32_t current_resource_index; /**< Current resource */
+int32_t current_resource_index;/**< Index of the current
resource in resources,
+or < 0 if a current
resource has yet to be selected */
int64_t last_pts; /**< Last timestamp */
} IMFVirtualTrackPlaybackCtx;
@@ -435,7 +436,6 @@ static int open_track_file_resource(AVFormatContext *s,
IMFContext *c = s->priv_data;
IMFAssetLocator *asset_locator;
void *tmp;
-int ret;
asset_locator = find_asset_map_locator(&c->asset_locator_map,
track_file_resource->track_file_uuid);
if (!asset_locator) {
@@ -452,7 +452,7 @@ static int open_track_file_resource(AVFormatContext *s,
UID_ARG(asset_locator->uuid),
asset_locator->absolute_uri);
-if (track->resource_count > UINT32_MAX -
track_file_resource->base.repeat_count
+if (track->resource_count > INT32_MAX -
track_file_resource->base.repeat_count
|| (track->resource_count + track_file_resource->base.repeat_count)
> INT_MAX / sizeof(IMFVirtualTrackResourcePlaybackCtx))
return AVERROR(ENOMEM);
@@ -470,8 +470,6 @@ static int open_track_file_resource(AVFormatContext *s,
vt_ctx.locator = asset_locator;
vt_ctx.resource = track_file_resource;
vt_ctx.ctx = NULL;
-if ((ret = open_track_resource_context(s, &vt_ctx)) != 0)
-return ret;
track->resources[track->resource_count++] = vt_ctx;
track->duration = av_add_q(track->duration,
av_make_q((int)track_file_resource->base.duration
@@ -501,6 +499,7 @@ static int open_virtual_track(AVFormatContext *s,
if (!(track = av_mallocz(sizeof(IMFVirtualTrackPlaybackCtx
return AVERROR(ENOMEM);
+track->current_resource_index = -1;
track->index = track_index;
track->duration = av_make_q(0, 1);
@@ -551,6 +550,7 @@ static int set_context_streams_from_tracks(AVFormatContext
*s)
AVStream *first_resource_stream;
/* Open the first resource of the track to get stream information */
+open_track_resource_context(s, &c->tracks[i]->resources[0]);
first_resource_stream = c->tracks[i]->resources[0].ctx->streams[0];
av_log(s, AV_LOG_DEBUG, "Open the first resource of track %d\n",
c->tracks[i]->index);
@@ -741,7 +741,8 @@ static IMFVirtualTrackResourcePlaybackCtx
*get_resource_context_for_timestamp(AV
track->index);
if (open_track_resource_context(s, &(track->resources[i])) !=
0)
return NULL;
-
avformat_close_input(&(track->resources[track->current_resource_index].ctx));
+if (track->current_resource_index > 0)
+
avformat_close_input(&track->resources[track->current_resource_index].ctx);
track->current_resource_index = i;
}
--
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] [PATCH v3 2/4] avformat/imf: fix missing error reporting when opening resources
From: Pierre-Anthony Lemieux --- libavformat/imfdec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c index e6a1020ecc..658ddc40f2 100644 --- a/libavformat/imfdec.c +++ b/libavformat/imfdec.c @@ -550,7 +550,9 @@ static int set_context_streams_from_tracks(AVFormatContext *s) AVStream *first_resource_stream; /* Open the first resource of the track to get stream information */ -open_track_resource_context(s, &c->tracks[i]->resources[0]); +ret = open_track_resource_context(s, &c->tracks[i]->resources[0]); +if (ret) +return ret; first_resource_stream = c->tracks[i]->resources[0].ctx->streams[0]; av_log(s, AV_LOG_DEBUG, "Open the first resource of track %d\n", c->tracks[i]->index); -- 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] [PATCH v3 3/4] avformat/imf: fix packet pts, dts and muxing
From: Pierre-Anthony Lemieux
The IMF demuxer does not set the DTS and PTS of packets accurately in all
scenarios. Moreover, audio packets are not trimmed when they exceed the
duration of the underlying resource.
imf-cpl-with-repeat FATE ref file is regenerated.
Addresses https://trac.ffmpeg.org/ticket/9611
---
libavformat/imfdec.c | 263 +++--
tests/ref/fate/imf-cpl-with-repeat | 20 +--
2 files changed, 181 insertions(+), 102 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index 658ddc40f2..5be4411cb1 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -65,8 +65,10 @@
#include "avio_internal.h"
#include "imf.h"
#include "internal.h"
+#include "libavcodec/packet.h"
#include "libavutil/avstring.h"
#include "libavutil/bprint.h"
+#include "libavutil/intreadwrite.h"
#include "libavutil/opt.h"
#include "mxf.h"
#include "url.h"
@@ -97,6 +99,9 @@ typedef struct IMFVirtualTrackResourcePlaybackCtx {
IMFAssetLocator *locator;
FFIMFTrackFileResource *resource;
AVFormatContext *ctx;
+AVRational start_time;
+AVRational end_time;
+AVRational ts_offset;
} IMFVirtualTrackResourcePlaybackCtx;
typedef struct IMFVirtualTrackPlaybackCtx {
@@ -108,7 +113,6 @@ typedef struct IMFVirtualTrackPlaybackCtx {
IMFVirtualTrackResourcePlaybackCtx *resources; /**< Buffer holding the
resources */
int32_t current_resource_index;/**< Index of the current
resource in resources,
or < 0 if a current
resource has yet to be selected */
-int64_t last_pts; /**< Last timestamp */
} IMFVirtualTrackPlaybackCtx;
typedef struct IMFContext {
@@ -342,6 +346,7 @@ static int open_track_resource_context(AVFormatContext *s,
int ret = 0;
int64_t entry_point;
AVDictionary *opts = NULL;
+AVStream *st;
if (track_resource->ctx) {
av_log(s,
@@ -383,23 +388,28 @@ static int open_track_resource_context(AVFormatContext *s,
}
av_dict_free(&opts);
-/* Compare the source timebase to the resource edit rate,
- * considering the first stream of the source file
- */
-if (av_cmp_q(track_resource->ctx->streams[0]->time_base,
- av_inv_q(track_resource->resource->base.edit_rate)))
+/* make sure there is only one stream in the file */
+
+if (track_resource->ctx->nb_streams != 1) {
+ret = AVERROR_INVALIDDATA;
+goto cleanup;
+}
+
+st = track_resource->ctx->streams[0];
+
+/* Warn if the resource time base does not match the file time base */
+if (av_cmp_q(st->time_base,
av_inv_q(track_resource->resource->base.edit_rate)))
av_log(s,
AV_LOG_WARNING,
- "Incoherent source stream timebase %d/%d regarding resource
edit rate: %d/%d",
- track_resource->ctx->streams[0]->time_base.num,
- track_resource->ctx->streams[0]->time_base.den,
+ "Incoherent source stream timebase " AVRATIONAL_FORMAT
+ "regarding resource edit rate: " AVRATIONAL_FORMAT,
+ st->time_base.num,
+ st->time_base.den,
track_resource->resource->base.edit_rate.den,
track_resource->resource->base.edit_rate.num);
-entry_point = (int64_t)track_resource->resource->base.entry_point
-* track_resource->resource->base.edit_rate.den
-* AV_TIME_BASE
-/ track_resource->resource->base.edit_rate.num;
+entry_point = av_rescale_q(track_resource->resource->base.entry_point,
st->time_base,
+
av_inv_q(track_resource->resource->base.edit_rate));
if (entry_point) {
av_log(s,
@@ -407,7 +417,7 @@ static int open_track_resource_context(AVFormatContext *s,
"Seek at resource %s entry point: %" PRIu32 "\n",
track_resource->locator->absolute_uri,
track_resource->resource->base.entry_point);
-ret = avformat_seek_file(track_resource->ctx, -1, entry_point,
entry_point, entry_point, 0);
+ret = avformat_seek_file(track_resource->ctx, 0, entry_point,
entry_point, entry_point, 0);
if (ret < 0) {
av_log(s,
AV_LOG_ERROR,
@@ -470,11 +480,16 @@ static int open_track_file_resource(AVFormatContext *s,
vt_ctx.locator = asset_locator;
vt_ctx.resource = track_file_resource;
vt_ctx.ctx = NULL;
-track->resources[track->resource_count++] = vt_ctx;
-track->duration = av_add_q(track->duration,
+vt_ctx.start_time = track->duration;
+vt_ctx.ts_offset = av_sub_q(vt_ctx.start_time,
+
av_div_q(av_make_q((int)track_file_resource->base.entry_point, 1),
+
track_file_resource->base.edit_rate));
+vt_ctx.end_time = av_add_q(track->duration,
[FFmpeg-devel] [PATCH v3 4/4] avformat/imf: document IMFVirtualTrackResourcePlaybackCtx
From: Pierre-Anthony Lemieux
---
libavformat/imfdec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index 5be4411cb1..02e7bcc33f 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -96,12 +96,12 @@ typedef struct IMFAssetLocatorMap {
} IMFAssetLocatorMap;
typedef struct IMFVirtualTrackResourcePlaybackCtx {
-IMFAssetLocator *locator;
-FFIMFTrackFileResource *resource;
-AVFormatContext *ctx;
-AVRational start_time;
-AVRational end_time;
-AVRational ts_offset;
+IMFAssetLocator *locator; /**< Location of the resource */
+FFIMFTrackFileResource *resource; /**< Underlying IMF CPL resource */
+AVFormatContext *ctx; /**< Context associated with the
resource */
+AVRational start_time; /**< inclusive start time of the
resource on the CPL timeline (s) */
+AVRational end_time; /**< exclusive end time of the resource
on the CPL timeline (s) */
+AVRational ts_offset; /**< start_time minus the entry point
into the resource (s) */
} IMFVirtualTrackResourcePlaybackCtx;
typedef struct IMFVirtualTrackPlaybackCtx {
--
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".
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On Wed, 26 Jan 2022 at 15:00, Martin Storsjö wrote: > > Hi, > > On Sat, 22 Jan 2022, Kacper Michajłow wrote: > > > LLVM tools print installation path upon execution. If one uses LLVM > > tools bundled with Microsoft Visual Studio installation, they would be > > incorrectly detected as Microsoft's ones. > > > > Signed-off-by: Kacper Michajłow > > --- > > configure | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > While the patch description seems to make sense, I wanted to try it out to > see the practical effect for myself, and I fail to observe any difference. > > Can you provide your exact configure command line you use, where it makes > a difference? I tried with "--cc=clang-cl --ld=lld-link --toolchain=msvc" > and that works just as fine before this patch. > > In particular, the commands that you adjust run "$_cc -nologo-" and grep > for "Microsoft" in the output of that. When I run that with clang-cl, it > doesn't print a string containing "Microsoft". > > // Martin Hi, Yes you are right. In case of CC it doesn't change anything. clang-cl prints installation dir only with `-v`. The main thing this patch fixes is `--ar=llvm-ar` where it is mistaken for lib.exe and used with wrong parameters. While fixing this I figured to make CC check also more strict, because at some point it could be a problem. Sync all of them to have same style as one that was already there > elif $_cc 2>&1 | grep -q 'Microsoft.*ARM.*Assembler'; then just for consistency... Also I noticed that latest MSVC (19.30.30709) complains about > cl : Command line warning D9035 : option 'nologo-' has been deprecated and > will be removed in a future release But it doesn't affect anything, even if it were to be removed. Since banner is shown always by default, unless `-nologo`. Just a side note :) -Kacper ___ 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".
