[FFmpeg-devel] [PATCH 0/1] Fix detecting ATRAC3 audio from MPS files
From: Misty De Meo > I think this might be worth a small fate test, assuming small samples > can be found and shared. Good idea. I've added a fate test, using one PSMF sample and one MPS sample. Here are URLs to the files: https://public.drac.at/6.MPS http://samples.ffmpeg.org/PSMF/EV01_01_0500D.PMF Misty De Meo (1): psmf: add FATE tests tests/Makefile | 1 + tests/fate/psmf.mak | 23 +++ 2 files changed, 24 insertions(+) create mode 100644 tests/fate/psmf.mak -- 2.15.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] psmf: add FATE tests
From: Misty De Meo --- tests/Makefile | 1 + tests/fate/psmf.mak | 23 +++ 2 files changed, 24 insertions(+) create mode 100644 tests/fate/psmf.mak diff --git a/tests/Makefile b/tests/Makefile index fd3713fe81..c569091fcb 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -165,6 +165,7 @@ include $(SRC_PATH)/tests/fate/pcm.mak include $(SRC_PATH)/tests/fate/pixlet.mak include $(SRC_PATH)/tests/fate/probe.mak include $(SRC_PATH)/tests/fate/prores.mak +include $(SRC_PATH)/tests/fate/psmf.mak include $(SRC_PATH)/tests/fate/qt.mak include $(SRC_PATH)/tests/fate/qtrle.mak include $(SRC_PATH)/tests/fate/real.mak diff --git a/tests/fate/psmf.mak b/tests/fate/psmf.mak new file mode 100644 index 00..dc3a56b19e --- /dev/null +++ b/tests/fate/psmf.mak @@ -0,0 +1,23 @@ +# +# Test detecting ATRAC-3 audio in Sony MPEG files +# + +PROBE_CODEC_NAME_COMMAND = \ + ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream=codec_name \ + -select_streams a -print_format default=noprint_wrappers=1 -bitexact -v 0 + +FATE_PSMF_FFPROBE = fate-psmf-probe-6 \ + fate-psmf-probe-EV01_01_0500D + +fate-psmf-probe-6: SRC = $(TARGET_SAMPLES)/psmf/6.MPS +fate-psmf-probe-6: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)" +fate-psmf-probe-6: CMP = oneline +fate-psmf-probe-6: REF = codec_name=atrac3p +fate-psmf-probe-EV01_01_0500D: SRC = $(TARGET_SAMPLES)/psmf/EV01_01_0500D.PMF +fate-psmf-probe-EV01_01_0500D: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)" +fate-psmf-probe-EV01_01_0500D: CMP = oneline +fate-psmf-probe-EV01_01_0500D: REF = codec_name=atrac3p + +FATE_SAMPLES_FFPROBE += $(FATE_PSMF_FFPROBE) + +fate-psmf: $(FATE_PSMF_PROBE) -- 2.15.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers
On Sun, Dec 24, 2017 at 02:31:16AM +0100, wm4 wrote:
> On Sun, 24 Dec 2017 02:06:40 +0100
> Michael Niedermayer wrote:
>
> > If you and others agree we can also easily maintain support for user apps
> > to register codecs. The only thing needed is to make the array bigger and
> > add codecs which arent ours in there as long as there is space.
> > doing this would be very easy, a atomic integer pointing to the begin of
> > the free space which is atomically increased for each register is all that
> > is needed
>
> Not sure how often I repeated this (specifically for you), but:
why are you so upset ? We have different oppinions here or we misunderstand
each other.
>
> - users can't provide AVCodec, because it would require accessing
> internal API and private ABI unstable fields
That is expected without there being an effort to design a public API
for external codecs.
Point being, this doesnt matter.
One can still maintain an external codec register it and use it.
It would need to be rebuild for each libavcodec version and would
occasionally need to be changed like any internal codec.
But it would not be harder than maintaining a codec inside ffmpeg.
Especially if one targets a release like 3.4.x it would be close to 0
work to have a external codec that is registered compared to having it
internal
> - if we provide the ability to add user codecs (which I'm not
> fundamentally against), then it should not modify global state.
> Having named user codecs in a process wide list would definitely lead
> to name clashes or other conflicts
I dont see how you could do this without modifying global state.
You would need some kind of context for all codec "lookup" functions
Such context could be added and iam not against this at all, but i feel
this is fixing a problem noone has ever had. registering codecs was
supported since forever and ive never heared of a conflict like you describe
> - also, we would have to provide stable/public API for implementing
> codecs in the first place (all AVCodec callback fields are private),
> and we're nowhere near the state of adding it
I would love to see such a API and i would certainly contribute but
as explained above, we dont have it and we dont really need it for
registering user codec to be usefull in practice IMO
> - dropping avcodec_register() is definitely not the worst blocker for
> user codecs - it's very, very far from it, because once we have
> fixed the things above, we can just add a new public API for
> registering (which would have to have a different function signature
> to avoid global mutable lists). So I don't know why you complain.
Like elaborated above, it is the main problem.
Currently external codecs are possible for all i know. And i have
seen it used a few years ago, so it did work at some point in real
applications.
> - these points are technical, not ideological
>
> Can you point out any user application which registers its own codecs
> (and this violates the API)?
I do not remember which application it was but i did a few years ago review
all user apps using libavcodec / libavformat for things we could merge.
I do remember seeing some that added codecs.
It was some code that was very specific to the app or platform IIRC
There are more usecases. For example codec optimizations for niche
codecs where rejected on ffmpeg-devel.
I find it unfriendly from us if we reject improvments because they
arent in a area most of us care and then also drop the possibility
for externally maintaining and registering code without doing a
full fork (which is much more work to maintain)
>
> > > +AVCodec *av_codec_next(const AVCodec *c)
> > > +{
> > > +pthread_once(&av_codec_next_init, av_codec_init_next);
> > > +
> > > +if (c)
> > > +return c->next;
> >
> > AVCodec->next should be removed as it makes the structs non constant
>
> That has to happen after a deprecation phase, unless you have an idea
> how to make av_codec_next() not O(n^2) without this.
That can be done and there are many ways. Not saying we want to do it
first possibility, one can add a int "constant" to each AVCodec.
configure would have to choose these or there would be holes in the array.
a hashtable with a mutex is an option too but that seems not worth the
complexity / work
the 3rd obvious option is to make "next" a pointer to a int which is
initialized in each codec to some static int. Which can then be set
to the array index, the main struct can then remain in read only memory
iam pretty sure there are many more options
PS: merry Xmas!
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
signature.asc
Description: PGP signature
___
Re: [FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers
On 24 December 2017 at 11:43, Michael Niedermayer wrote: > On Sun, Dec 24, 2017 at 02:31:16AM +0100, wm4 wrote: > > On Sun, 24 Dec 2017 02:06:40 +0100 > > Michael Niedermayer wrote: > > > > > If you and others agree we can also easily maintain support for user > apps > > > to register codecs. The only thing needed is to make the array bigger > and > > > add codecs which arent ours in there as long as there is space. > > > doing this would be very easy, a atomic integer pointing to the begin > of > > > the free space which is atomically increased for each register is all > that > > > is needed > > > > Not sure how often I repeated this (specifically for you), but: > > why are you so upset ? We have different oppinions here or we misunderstand > each other. > > > > > > - users can't provide AVCodec, because it would require accessing > > internal API and private ABI unstable fields > > That is expected without there being an effort to design a public API > for external codecs. > > Point being, this doesnt matter. > One can still maintain an external codec register it and use it. > It would need to be rebuild for each libavcodec version and would > occasionally need to be changed like any internal codec. > But it would not be harder than maintaining a codec inside ffmpeg. > > Especially if one targets a release like 3.4.x it would be close to 0 > work to have a external codec that is registered compared to having it > internal > > Stop derailing the thread, both of you. We're not going to support external codecs now, nor in the future. This has been discussed before. Much of the work that would be done on supporting external codecs is better spent with a disassembler on some binary of a yet another H264/HEVC copy. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] oma: move some constants into libavcodec
On 24 December 2017 at 04:48, wrote:
> From: Misty De Meo
>
> Most of the constants in libavcodec/oma aren't specific to
> libavformat; moving them into libavcodec makes them available to
> libavcodec as well as keeping them compatible with libavformat.
>
> ff_oma_codec_tags uses a libavformat-specific type, so it has been
> left in libavformat.
> ---
> libavformat/oma.c => libavcodec/oma.h | 27 +--
> libavcodec/version.h | 2 +-
> libavformat/Makefile | 4 ++--
> libavformat/oma.h | 21 +
> libavformat/omadec.c | 1 +
> libavformat/omaenc.c | 1 +
> libavformat/version.h | 2 +-
> 7 files changed, 28 insertions(+), 30 deletions(-)
> rename libavformat/oma.c => libavcodec/oma.h (65%)
>
> diff --git a/libavformat/oma.c b/libavcodec/oma.h
> similarity index 65%
> rename from libavformat/oma.c
> rename to libavcodec/oma.h
> index f7ae3c9948..176f93ed22 100644
> --- a/libavformat/oma.c
> +++ b/libavcodec/oma.h
> @@ -18,25 +18,22 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> */
>
> +#ifndef AVCODEC_OMA_H
> +#define AVCODEC_OMA_H
> +
> +#include
> +
> #include "internal.h"
> -#include "oma.h"
> -#include "libavcodec/avcodec.h"
> #include "libavutil/channel_layout.h"
>
> -const uint16_t ff_oma_srate_tab[8] = { 320, 441, 480, 882, 960, 0 };
> +#define EA3_HEADER_SIZE 96
> +#define ID3v2_EA3_MAGIC "ea3"
> +#define OMA_ENC_HEADER_SIZE 16
>
> -const AVCodecTag ff_oma_codec_tags[] = {
> -{ AV_CODEC_ID_ATRAC3, OMA_CODECID_ATRAC3},
> -{ AV_CODEC_ID_ATRAC3P, OMA_CODECID_ATRAC3P },
> -{ AV_CODEC_ID_MP3, OMA_CODECID_MP3 },
> -{ AV_CODEC_ID_PCM_S16BE, OMA_CODECID_LPCM },
> -{ AV_CODEC_ID_ATRAC3PAL, OMA_CODECID_ATRAC3PAL },
> -{ AV_CODEC_ID_ATRAC3AL,OMA_CODECID_ATRAC3AL },
> -{ 0 },
> -};
> +static const uint16_t ff_oma_srate_tab[8] = { 320, 441, 480, 882, 960, 0
> };
>
> /** map ATRAC-X channel id to internal channel layout */
> -const uint64_t ff_oma_chid_to_native_layout[7] = {
> +static const uint64_t ff_oma_chid_to_native_layout[7] = {
> AV_CH_LAYOUT_MONO,
> AV_CH_LAYOUT_STEREO,
> AV_CH_LAYOUT_SURROUND,
> @@ -47,4 +44,6 @@ const uint64_t ff_oma_chid_to_native_layout[7] = {
> };
>
> /** map ATRAC-X channel id to total number of channels */
> -const int ff_oma_chid_to_num_channels[7] = {1, 2, 3, 4, 6, 7, 8};
> +static const int ff_oma_chid_to_num_channels[7] = {1, 2, 3, 4, 6, 7, 8};
> +
> +#endif /* AVCODEC_OMA_H */
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index d55de89797..d48857578d 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>
> #define LIBAVCODEC_VERSION_MAJOR 58
> #define LIBAVCODEC_VERSION_MINOR 8
> -#define LIBAVCODEC_VERSION_MICRO 100
> +#define LIBAVCODEC_VERSION_MICRO 101
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR,
> \
> LIBAVCODEC_VERSION_MINOR, \
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index cb70eac920..ef0365e6e2 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -358,8 +358,8 @@ OBJS-$(CONFIG_OGG_MUXER) += oggenc.o \
> vorbiscomment.o
> OBJS-$(CONFIG_OGV_MUXER) += oggenc.o \
> vorbiscomment.o
> -OBJS-$(CONFIG_OMA_DEMUXER) += omadec.o pcm.o oma.o
> -OBJS-$(CONFIG_OMA_MUXER) += omaenc.o rawenc.o oma.o
> id3v2enc.o
> +OBJS-$(CONFIG_OMA_DEMUXER) += omadec.o pcm.o
> +OBJS-$(CONFIG_OMA_MUXER) += omaenc.o rawenc.o id3v2enc.o
> OBJS-$(CONFIG_OPUS_MUXER)+= oggenc.o \
> vorbiscomment.o
> OBJS-$(CONFIG_PAF_DEMUXER) += paf.o
> diff --git a/libavformat/oma.h b/libavformat/oma.h
> index 36fd0125e4..ccd57d779e 100644
> --- a/libavformat/oma.h
> +++ b/libavformat/oma.h
> @@ -21,14 +21,8 @@
> #ifndef AVFORMAT_OMA_H
> #define AVFORMAT_OMA_H
>
> -#include
> -
> #include "internal.h"
>
> -#define EA3_HEADER_SIZE 96
> -#define ID3v2_EA3_MAGIC "ea3"
> -#define OMA_ENC_HEADER_SIZE 16
> -
> enum {
> OMA_CODECID_ATRAC3 = 0,
> OMA_CODECID_ATRAC3P = 1,
> @@ -39,11 +33,14 @@ enum {
> OMA_CODECID_ATRAC3AL = 34,
> };
>
> -extern const uint16_t ff_oma_srate_tab[8];
> -
> -extern const AVCodecTag ff_oma_codec_tags[];
> -
> -extern const uint64_t ff_oma_chid_to_native_layout[7];
> -extern const int ff_oma_chid_to_num_channels[7];
> +static const AVCodecTag ff_oma_codec_tags[] = {
> +{ AV_CODEC_ID_ATRAC3, OMA_CODECID_ATRAC3},
> +{ AV_CODEC_ID_ATRAC3P, OMA_CODECID_ATRAC3P },
> +{ AV_CODEC_ID_MP3, OMA_CODECID_MP3 },
> +{ AV_CODEC_ID_PCM_S16BE,
Re: [FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers
On Sat, Dec 23, 2017 at 8:27 PM, Josh de Kock wrote: > This is the first patch to add the new API for iterating items within the > libraries to lavc, this completes lavc's support for this API (BSFs were > already using it). > > I'm currently working on a similar patch for lavfi, lavf and lavd. Note that > I'm not entirely sure how to properly deprecate stuff so if that's incorrect > some advice would be appreciated. > > -- > Josh de Kock >+ >+#include "codec_list.c" >+ Building outside ffmpeg tree, I got CC libavcodec/allcodecs.o CC libavcodec/alsdec.o src/libavcodec/allcodecs.c:756:24: fatal error: codec_list.c: No such file or directory compilation terminated. Also, the patch contains tabs and trailing whitespace. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers
On 12/24/2017 8:43 AM, Michael Niedermayer wrote: > On Sun, Dec 24, 2017 at 02:31:16AM +0100, wm4 wrote: >> On Sun, 24 Dec 2017 02:06:40 +0100 >> Michael Niedermayer wrote: >> >>> If you and others agree we can also easily maintain support for user apps >>> to register codecs. The only thing needed is to make the array bigger and >>> add codecs which arent ours in there as long as there is space. >>> doing this would be very easy, a atomic integer pointing to the begin of >>> the free space which is atomically increased for each register is all that >>> is needed >> >> Not sure how often I repeated this (specifically for you), but: > > why are you so upset ? We have different oppinions here or we misunderstand > each other. > > >> >> - users can't provide AVCodec, because it would require accessing >> internal API and private ABI unstable fields > > That is expected without there being an effort to design a public API > for external codecs. > > Point being, this doesnt matter. > One can still maintain an external codec register it and use it. > It would need to be rebuild for each libavcodec version and would > occasionally need to be changed like any internal codec. > But it would not be harder than maintaining a codec inside ffmpeg. Every project that requires some custom addition to what ffmpeg offers will and should implement them into their own public fork of ffmpeg as lgpl expects them to, and right now that includes custom modules like codecs, muxers and such. Said changes can then be upstreamed if needed/useful. The API does not allow them to register their own codecs. We could right now move all the "private" AVCodec fields into an internal opaque struct while keeping the codec register API untouched and it wouldn't be an API break of any kind, yet it would prevent people from abusing it and registering their own Frankencodecs. So yes, it's literally a side effect of us putting internal fields in public headers, an awful practice that no one else does, probably because of reasons like the one we're discussing. Furthermore, we did what this patch is doing with hwaccels a month or so ago, and it wasn't an issue. Same with bsfs like a year ago. This is simply the next step. > > Especially if one targets a release like 3.4.x it would be close to 0 > work to have a external codec that is registered compared to having it > internal > > >> - if we provide the ability to add user codecs (which I'm not >> fundamentally against), then it should not modify global state. >> Having named user codecs in a process wide list would definitely lead >> to name clashes or other conflicts > > I dont see how you could do this without modifying global state. > You would need some kind of context for all codec "lookup" functions > > Such context could be added and iam not against this at all, but i feel > this is fixing a problem noone has ever had. registering codecs was > supported since forever and ive never heared of a conflict like you describe > > >> - also, we would have to provide stable/public API for implementing >> codecs in the first place (all AVCodec callback fields are private), >> and we're nowhere near the state of adding it > > I would love to see such a API and i would certainly contribute but > as explained above, we dont have it and we dont really need it for > registering user codec to be usefull in practice IMO > > >> - dropping avcodec_register() is definitely not the worst blocker for >> user codecs - it's very, very far from it, because once we have >> fixed the things above, we can just add a new public API for >> registering (which would have to have a different function signature >> to avoid global mutable lists). So I don't know why you complain. > > Like elaborated above, it is the main problem. > Currently external codecs are possible for all i know. And i have > seen it used a few years ago, so it did work at some point in real > applications. > > >> - these points are technical, not ideological >> >> Can you point out any user application which registers its own codecs >> (and this violates the API)? > > I do not remember which application it was but i did a few years ago review > all user apps using libavcodec / libavformat for things we could merge. > I do remember seeing some that added codecs. > It was some code that was very specific to the app or platform IIRC "People in the past misused the API. What if they still do?" is not a good reason to prevent development and improvements to our codebase. People will always misuse the API when they can, and it should never be a reason to condition development. Just look at how things were with mplayer for the longest time. > > There are more usecases. For example codec optimizations for niche > codecs where rejected on ffmpeg-devel. > I find it unfriendly from us if we reject improvments because they > arent in a area most of us care and then also drop the possibility > for externally maintaini
[FFmpeg-devel] Public and private structs and fields (was: lavc: add new API for iterating codecs) and codec parsers
I fully agree with the point you are making, but there is an argument you are invoking that I do not agree with at all. James Almer (2017-12-24): > So yes, it's literally a side effect of us putting internal fields in > public headers, an awful practice that no one else does No one else, except glibc, OpenBSD, Gtk+ (until the Gnome guys took over), which are just the examples that come to mind immediately. the need for having internal fields in public headers is a consequence of the design of the C language. There are other languages that offer better options, but they all have also drawbacks in other area, and I am pretty sure the vast majority here would rightly be against reimplementing FFmpeg as a C++ or Rust project. There are also other options within the C language, but they all have huge drawbacks. So when you are saying that it is an awful practice, it is the same as with Churchill's quote about democracy being the worst form of government: it is an awful practice, but all other practices to achieve the same result are even more awful. There may be a better solution that we have not thought of yet. But if you propose something, please stay open about the drawbacks that you may not have seen or may not affect your work flow. > People will always misuse the API when they can, and it should never be > a reason to condition development. I fully agree with that, but beware, I will keep you to it. It relates directly to the point above: if people are not able to read "this field is private, do not touch it", that does not mean we should make it public. But it does not mean that we should make complex efforts to hide them. > Merry Christmas :) I wonder what I should be merrier about: twenty centuries of dogmatic brainwashing, or the unbounded consumer society leading to a global ecologic catastrophe. Happy days-getting-longer to you all! Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers
On Sun, 24 Dec 2017 12:43:27 +0100 Michael Niedermayer wrote: > On Sun, Dec 24, 2017 at 02:31:16AM +0100, wm4 wrote: > > On Sun, 24 Dec 2017 02:06:40 +0100 > > Michael Niedermayer wrote: > > > > > If you and others agree we can also easily maintain support for user apps > > > to register codecs. The only thing needed is to make the array bigger and > > > add codecs which arent ours in there as long as there is space. > > > doing this would be very easy, a atomic integer pointing to the begin of > > > the free space which is atomically increased for each register is all that > > > is needed > > > > Not sure how often I repeated this (specifically for you), but: > > why are you so upset ? We have different oppinions here or we misunderstand > each other. Not necessarily upset, but this is tiring. Every time you bring this up, I have to repeat the arguments I made, and next time you seem to have forgotten about it. And then it always degenerates in a flame war. I don't need this. On the other hand, you seem to be upset about the removal of codec registering. I don't know why. As I've said, it didn't work anyway, unless you've used internal API/ABI. You seem to be raising a bit of a stink about it. In summary: - before this commit: you could not register user codecs, unless you've used unstable internal API and used ABI unstable internal fields, effectively binding to one FFmpeg version - after this commit: you can not register user codecs, even if you're willing to violate the API Not a big loss I think. Also you could still pass customs AVCodec to the codec context creation. > > > > - users can't provide AVCodec, because it would require accessing > > internal API and private ABI unstable fields > > That is expected without there being an effort to design a public API > for external codecs. > > Point being, this doesnt matter. > One can still maintain an external codec register it and use it. > It would need to be rebuild for each libavcodec version and would > occasionally need to be changed like any internal codec. > But it would not be harder than maintaining a codec inside ffmpeg. You're just as well off by patching the libavcodec to add your non-upstreamed codec. (Before this patch, you obviously had to have control over the libavcodec used, and now you can use your control over it to patch it in.) > Especially if one targets a release like 3.4.x it would be close to 0 > work to have a external codec that is registered compared to having it > internal > > > > - if we provide the ability to add user codecs (which I'm not > > fundamentally against), then it should not modify global state. > > Having named user codecs in a process wide list would definitely lead > > to name clashes or other conflicts > > I dont see how you could do this without modifying global state. > You would need some kind of context for all codec "lookup" functions > > Such context could be added and iam not against this at all, but i feel Yes. And this would require new API. Actually, I think you would just not register the codec at all, but pass it directly to AVCodecContext initialization (and for other components, anything that actually needs to access such lists). In fact you can still do this after this patch. avcodec_alloc_context3() takes a AVCodec pointer. You can pass a custom struct if you're willing to violate the public API. > this is fixing a problem noone has ever had. registering codecs was > supported since forever and ive never heared of a conflict like you describe I've never heard of any API user using custom registration. When I inquired about this in my previous mail, you couldn't name verifiable examples either. I know a bunch of programs that broke because libavformat removed custom protocol registration (and forced you to use a custom AVIO context instead), but apparently that hasn't been a problem for FFmpeg. > > > - also, we would have to provide stable/public API for implementing > > codecs in the first place (all AVCodec callback fields are private), > > and we're nowhere near the state of adding it > > I would love to see such a API and i would certainly contribute but > as explained above, we dont have it and we dont really need it for > registering user codec to be usefull in practice IMO Are you seriously arguing for API users to access internal API? And I bet some time later you could argue for avoiding internal API changes because some API users rely on it... This is not how it works. You're just setting us up for a maintenance nightmare. The whole point of separation FFmpeg into public and private API is to set a boundary so we can do anything at all without immediately breaking API users. > > > - dropping avcodec_register() is definitely not the worst blocker for > > user codecs - it's very, very far from it, because once we have > > fixed the things above, we can just add a new public API for > > registering (which would have t
Re: [FFmpeg-devel] Public and private structs and fields (was: lavc: add new API for iterating codecs) and codec parsers
Nicolas George wrote: >Happy days-getting-longer to you all! Is FFmpeg not working in the Southern Hemisphere? Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Public and private structs and fields (was: lavc: add new API for iterating codecs) and codec parsers
On 12/24/17, Reto Kromer wrote: > Nicolas George wrote: > >>Happy days-getting-longer to you all! > > Is FFmpeg not working in the Southern Hemisphere? Reto No, all devs are located in Austria. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Public and private structs and fields (was: lavc: add new API for iterating codecs) and codec parsers
On Sun, Dec 24, 2017, at 6:54 AM, Nicolas George wrote: > > ...or the unbounded consumer society leading to a global ecologic catastrophe. As I work in the multimedia field I am therefore too poor to participate in the consumer society. > Happy days-getting-longer to you all! What about the other half of the planet? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 3/5] ffplay: drop lock manager use
On Sun, 24 Dec 2017, wm4 wrote: Deprecated and useless. --- fftools/ffplay.c | 27 --- 1 file changed, 27 deletions(-) LGTM, thanks. Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavr: deprecate the entire library
Signed-off-by: Rostislav Pehlivanov
---
doc/APIchanges | 5 +
libavresample/avresample.h | 30 +-
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index df79758e86..96fad416d5 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
API changes, most recent first:
+2017-xx-xx - xxx - lavr 4.0.0 - avresample.h
+ Deprecate the entire library. It was unmaintained and redundant
+ as libswresample did everything it did better, faster, with more
+ control and with a better, slightly higher level API.
+
2017-12-xx - xxx - lavu 56.7.100 - cpu.h
AVX-512 flags added.
diff --git a/libavresample/avresample.h b/libavresample/avresample.h
index 193443e2a6..57889c572c 100644
--- a/libavresample/avresample.h
+++ b/libavresample/avresample.h
@@ -103,10 +103,10 @@
#define AVRESAMPLE_MAX_CHANNELS 32
-typedef struct AVAudioResampleContext AVAudioResampleContext;
+typedef attribute_deprecated struct AVAudioResampleContext
AVAudioResampleContext;
/** Mixing Coefficient Types */
-enum AVMixCoeffType {
+enum attribute_deprecated AVMixCoeffType {
AV_MIX_COEFF_TYPE_Q8, /** 16-bit 8.8 fixed-point */
AV_MIX_COEFF_TYPE_Q15, /** 32-bit 17.15 fixed-point*/
AV_MIX_COEFF_TYPE_FLT, /** floating-point */
@@ -114,13 +114,13 @@ enum AVMixCoeffType {
};
/** Resampling Filter Types */
-enum AVResampleFilterType {
+enum attribute_deprecated AVResampleFilterType {
AV_RESAMPLE_FILTER_TYPE_CUBIC, /**< Cubic */
AV_RESAMPLE_FILTER_TYPE_BLACKMAN_NUTTALL, /**< Blackman Nuttall Windowed
Sinc */
AV_RESAMPLE_FILTER_TYPE_KAISER, /**< Kaiser Windowed Sinc */
};
-enum AVResampleDitherMethod {
+enum attribute_deprecated AVResampleDitherMethod {
AV_RESAMPLE_DITHER_NONE,/**< Do not use dithering */
AV_RESAMPLE_DITHER_RECTANGULAR, /**< Rectangular Dither */
AV_RESAMPLE_DITHER_TRIANGULAR, /**< Triangular Dither*/
@@ -132,17 +132,20 @@ enum AVResampleDitherMethod {
/**
* Return the LIBAVRESAMPLE_VERSION_INT constant.
*/
+attribute_deprecated
unsigned avresample_version(void);
/**
* Return the libavresample build-time configuration.
* @return configure string
*/
+attribute_deprecated
const char *avresample_configuration(void);
/**
* Return the libavresample license.
*/
+attribute_deprecated
const char *avresample_license(void);
/**
@@ -155,6 +158,7 @@ const char *avresample_license(void);
*
* @return AVClass for AVAudioResampleContext
*/
+attribute_deprecated
const AVClass *avresample_get_class(void);
/**
@@ -162,6 +166,7 @@ const AVClass *avresample_get_class(void);
*
* @return allocated audio resample context, or NULL on failure
*/
+attribute_deprecated
AVAudioResampleContext *avresample_alloc_context(void);
/**
@@ -178,6 +183,7 @@ AVAudioResampleContext *avresample_alloc_context(void);
* @param avr audio resample context
* @return 0 on success, negative AVERROR code on failure
*/
+attribute_deprecated
int avresample_open(AVAudioResampleContext *avr);
/**
@@ -186,6 +192,7 @@ int avresample_open(AVAudioResampleContext *avr);
* @param avr AVAudioResampleContext to check
* @return 1 if avr is open, 0 if avr is closed.
*/
+attribute_deprecated
int avresample_is_open(AVAudioResampleContext *avr);
/**
@@ -201,6 +208,7 @@ int avresample_is_open(AVAudioResampleContext *avr);
*
* @param avr audio resample context
*/
+attribute_deprecated
void avresample_close(AVAudioResampleContext *avr);
/**
@@ -210,6 +218,7 @@ void avresample_close(AVAudioResampleContext *avr);
*
* @param avr audio resample context
*/
+attribute_deprecated
void avresample_free(AVAudioResampleContext **avr);
/**
@@ -234,6 +243,7 @@ void avresample_free(AVAudioResampleContext **avr);
* @param matrix_encoding matrixed stereo downmix mode (e.g. dplii)
* @return0 on success, negative AVERROR code on failure
*/
+attribute_deprecated
int avresample_build_matrix(uint64_t in_layout, uint64_t out_layout,
double center_mix_level, double surround_mix_level,
double lfe_mix_level, int normalize, double
*matrix,
@@ -251,6 +261,7 @@ int avresample_build_matrix(uint64_t in_layout, uint64_t
out_layout,
* @param stride distance between adjacent input channels in the matrix array
* @return0 on success, negative AVERROR code on failure
*/
+attribute_deprecated
int avresample_get_matrix(AVAudioResampleContext *avr, double *matrix,
int stride);
@@ -272,6 +283,7 @@ int avresample_get_matrix(AVAudioResampleContext *avr,
double *matrix,
* @param stride distance between adjacent input channels in the matrix array
* @return0 on success, negative AVERROR code
[FFmpeg-devel] [PATCH 1/6] oma: move some constants into libavcodec
From: Misty De Meo
Most of the constants in libavcodec/oma aren't specific to
libavformat; moving them into libavcodec makes them available to
libavcodec as well as keeping them compatible with libavformat.
ff_oma_codec_tags uses a libavformat-specific type, so it has been
left in libavformat.
---
libavformat/oma.c => libavcodec/oma.h | 27 +--
libavcodec/version.h | 2 +-
libavformat/Makefile | 4 ++--
libavformat/oma.h | 21 +
libavformat/omadec.c | 13 +++--
libavformat/omaenc.c | 7 ---
libavformat/version.h | 2 +-
7 files changed, 37 insertions(+), 39 deletions(-)
rename libavformat/oma.c => libavcodec/oma.h (65%)
diff --git a/libavformat/oma.c b/libavcodec/oma.h
similarity index 65%
rename from libavformat/oma.c
rename to libavcodec/oma.h
index f7ae3c9948..f091ef24ca 100644
--- a/libavformat/oma.c
+++ b/libavcodec/oma.h
@@ -18,25 +18,22 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#ifndef AVCODEC_OMA_H
+#define AVCODEC_OMA_H
+
+#include
+
#include "internal.h"
-#include "oma.h"
-#include "libavcodec/avcodec.h"
#include "libavutil/channel_layout.h"
-const uint16_t ff_oma_srate_tab[8] = { 320, 441, 480, 882, 960, 0 };
+#define EA3_HEADER_SIZE 96
+#define ID3v2_EA3_MAGIC "ea3"
+#define OMA_ENC_HEADER_SIZE 16
-const AVCodecTag ff_oma_codec_tags[] = {
-{ AV_CODEC_ID_ATRAC3, OMA_CODECID_ATRAC3},
-{ AV_CODEC_ID_ATRAC3P, OMA_CODECID_ATRAC3P },
-{ AV_CODEC_ID_MP3, OMA_CODECID_MP3 },
-{ AV_CODEC_ID_PCM_S16BE, OMA_CODECID_LPCM },
-{ AV_CODEC_ID_ATRAC3PAL, OMA_CODECID_ATRAC3PAL },
-{ AV_CODEC_ID_ATRAC3AL,OMA_CODECID_ATRAC3AL },
-{ 0 },
-};
+static const uint16_t oma_srate_tab[8] = { 320, 441, 480, 882, 960, 0 };
/** map ATRAC-X channel id to internal channel layout */
-const uint64_t ff_oma_chid_to_native_layout[7] = {
+static const uint64_t oma_chid_to_native_layout[7] = {
AV_CH_LAYOUT_MONO,
AV_CH_LAYOUT_STEREO,
AV_CH_LAYOUT_SURROUND,
@@ -47,4 +44,6 @@ const uint64_t ff_oma_chid_to_native_layout[7] = {
};
/** map ATRAC-X channel id to total number of channels */
-const int ff_oma_chid_to_num_channels[7] = {1, 2, 3, 4, 6, 7, 8};
+static const int oma_chid_to_num_channels[7] = {1, 2, 3, 4, 6, 7, 8};
+
+#endif /* AVCODEC_OMA_H */
diff --git a/libavcodec/version.h b/libavcodec/version.h
index d55de89797..d48857578d 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 8
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cb70eac920..ef0365e6e2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -358,8 +358,8 @@ OBJS-$(CONFIG_OGG_MUXER) += oggenc.o \
vorbiscomment.o
OBJS-$(CONFIG_OGV_MUXER) += oggenc.o \
vorbiscomment.o
-OBJS-$(CONFIG_OMA_DEMUXER) += omadec.o pcm.o oma.o
-OBJS-$(CONFIG_OMA_MUXER) += omaenc.o rawenc.o oma.o id3v2enc.o
+OBJS-$(CONFIG_OMA_DEMUXER) += omadec.o pcm.o
+OBJS-$(CONFIG_OMA_MUXER) += omaenc.o rawenc.o id3v2enc.o
OBJS-$(CONFIG_OPUS_MUXER)+= oggenc.o \
vorbiscomment.o
OBJS-$(CONFIG_PAF_DEMUXER) += paf.o
diff --git a/libavformat/oma.h b/libavformat/oma.h
index 36fd0125e4..41972830ec 100644
--- a/libavformat/oma.h
+++ b/libavformat/oma.h
@@ -21,14 +21,8 @@
#ifndef AVFORMAT_OMA_H
#define AVFORMAT_OMA_H
-#include
-
#include "internal.h"
-#define EA3_HEADER_SIZE 96
-#define ID3v2_EA3_MAGIC "ea3"
-#define OMA_ENC_HEADER_SIZE 16
-
enum {
OMA_CODECID_ATRAC3 = 0,
OMA_CODECID_ATRAC3P = 1,
@@ -39,11 +33,14 @@ enum {
OMA_CODECID_ATRAC3AL = 34,
};
-extern const uint16_t ff_oma_srate_tab[8];
-
-extern const AVCodecTag ff_oma_codec_tags[];
-
-extern const uint64_t ff_oma_chid_to_native_layout[7];
-extern const int ff_oma_chid_to_num_channels[7];
+static const AVCodecTag oma_codec_tags[] = {
+{ AV_CODEC_ID_ATRAC3, OMA_CODECID_ATRAC3},
+{ AV_CODEC_ID_ATRAC3P, OMA_CODECID_ATRAC3P },
+{ AV_CODEC_ID_MP3, OMA_CODECID_MP3 },
+{ AV_CODEC_ID_PCM_S16BE, OMA_CODECID_LPCM },
+{ AV_CODEC_ID_ATRAC3PAL, OMA_CODECID_ATRAC3PAL },
+{ AV_CODEC_ID_ATRAC3AL,OMA_CODECID_ATRAC3AL },
+{ 0 },
+};
#endif /* AVFORMAT_OMA_H */
diff --git a/libavformat/omadec.c b/libavformat/omadec.c
index 423d52b3aa..24afaa417b 100644
---
[FFmpeg-devel] [PATCH 3/6] atrac3plus_parser: use libavcodec's oma
From: Misty De Meo
---
libavcodec/atrac3plus_parser.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/atrac3plus_parser.c b/libavcodec/atrac3plus_parser.c
index 01fcad4c45..f58f3d58ef 100644
--- a/libavcodec/atrac3plus_parser.c
+++ b/libavcodec/atrac3plus_parser.c
@@ -20,7 +20,7 @@
#include "parser.h"
#include "get_bits.h"
-#include "libavformat/oma.h"
+#include "oma.h"
typedef struct Atrac3PlusParseContext {
ParseContext pc;
@@ -38,7 +38,7 @@ static int parse_sound_frame_header(Atrac3PlusParseContext *c,
return AVERROR_INVALIDDATA;
atrac_config = AV_RB16(&buf[2]);
-c->sample_rate = ff_oma_srate_tab[(atrac_config >> 13) & 7] * 100;
+c->sample_rate = oma_srate_tab[(atrac_config >> 13) & 7] * 100;
c->channel_id = (atrac_config >> 10) & 7;
c->frame_size = ((atrac_config & 0x3FF) * 8) + 8;
@@ -120,8 +120,8 @@ static int ff_atrac3p_parse(AVCodecParserContext *s,
avctx->sample_rate= ctx->sample_rate;
avctx->block_align= ctx->frame_size;
avctx->bit_rate = ctx->sample_rate * ctx->frame_size * 8 / 2048;
-avctx->channels = ff_oma_chid_to_num_channels[ctx->channel_id -
1];
-avctx->channel_layout = ff_oma_chid_to_native_layout[ctx->channel_id -
1];
+avctx->channels = oma_chid_to_num_channels[ctx->channel_id - 1];
+avctx->channel_layout = oma_chid_to_native_layout[ctx->channel_id - 1];
next += hdr_bytes;
buf += hdr_bytes;
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/6] Fix detecting ATRAC3 audio from MPS files
From: Misty De Meo
MPS files are MPEG files used on PSP Video discs. They lack
the PSMF header used by .pms files, and so the special casing
in the original patch fails to support their audio. This patch
fixes this by unconditionally reading a new byte for the startcode
for PRIVATE_STREAM_1 sections, and doing the comparison on that
to find ATRAC-3 streams. In my testing, it works fine for both MPS
and PSMF files.
---
Changelog | 1 +
libavformat/mpeg.c | 38 ++
libavformat/mpeg.h | 1 +
3 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/Changelog b/Changelog
index ee48876128..67f28ea839 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,7 @@ version :
- video setrange filter
- nsp demuxer
- support LibreSSL (via libtls)
+- ATRAC-3 support for Sony PSP MPEG files
version 3.4:
diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index 895c6fb231..a366ece0ed 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -128,7 +128,6 @@ typedef struct MpegDemuxContext {
int sofdec;
int dvd;
int imkh_cctv;
-int sony_psmf; // true if Play Station Movie file signature is present
#if CONFIG_VOBSUB_DEMUXER
AVFormatContext *sub_ctx;
FFDemuxSubtitlesQueue q[32];
@@ -148,8 +147,6 @@ static int mpegps_read_header(AVFormatContext *s)
avio_get_str(s->pb, 6, buffer, sizeof(buffer));
if (!memcmp("IMKH", buffer, 4)) {
m->imkh_cctv = 1;
-} else if (!memcmp("PSMF00", buffer, 6)) {
-m->sony_psmf = 1;
} else if (!memcmp("Sofdec", buffer, 6)) {
m->sofdec = 1;
} else
@@ -444,7 +441,7 @@ redo:
goto redo;
}
-if (startcode == PRIVATE_STREAM_1 && !m->sony_psmf) {
+if (startcode == PRIVATE_STREAM_1) {
startcode = avio_r8(s->pb);
len--;
}
@@ -544,28 +541,21 @@ redo:
else
request_probe= 1;
type = AVMEDIA_TYPE_VIDEO;
-} else if (startcode == PRIVATE_STREAM_1 && m->sony_psmf) {
-uint8_t stream_id;
-
-if (len < 2)
-goto skip;
-stream_id = avio_r8(s->pb);
+// Sony PSP video with ATRAC-3 audio
+} else if (!(startcode & STREAM_TYPE_AUDIO_ATRAC3)) {
avio_r8(s->pb); // skip padding
-len -= 2;
-if (!(stream_id & 0xF0)) { // seems like we got an ATRAC stream
-/* check if an appropriate stream already exists */
-for (i = 0; i < s->nb_streams; i++) {
-st = s->streams[i];
-if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
-st->codec->codec_id == AV_CODEC_ID_ATRAC3P &&
-st->id - 0x1BD0 == (stream_id & 0xF))
-goto found;
-}
-
-startcode = 0x1BD0 + (stream_id & 0xF);
-type = AVMEDIA_TYPE_AUDIO;
-codec_id = AV_CODEC_ID_ATRAC3P;
+len--;
+for (i = 0; i < s->nb_streams; i++) {
+st = s->streams[i];
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
+st->codec->codec_id == AV_CODEC_ID_ATRAC3P &&
+st->id - 0x1BD0 == (startcode & 0xF))
+goto found;
}
+
+startcode = 0x1BD0 + (startcode & 0xF);
+type = AVMEDIA_TYPE_AUDIO;
+codec_id = AV_CODEC_ID_ATRAC3P;
} else if (startcode == PRIVATE_STREAM_2) {
type = AVMEDIA_TYPE_DATA;
codec_id = AV_CODEC_ID_DVD_NAV;
diff --git a/libavformat/mpeg.h b/libavformat/mpeg.h
index 617e36cba8..efbadec8ba 100644
--- a/libavformat/mpeg.h
+++ b/libavformat/mpeg.h
@@ -58,6 +58,7 @@
#define STREAM_TYPE_VIDEO_CAVS 0x42
#define STREAM_TYPE_AUDIO_AC3 0x81
+#define STREAM_TYPE_AUDIO_ATRAC30xF0
static const int lpcm_freq_tab[4] = { 48000, 96000, 44100, 32000 };
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/6] oma: move some constants into libavcodec
From: Misty De Meo > Code in header files which gets inlined doesn't need an ff_ prefix. Sounds good! I've updated the patchset to strip the ff_ prefix from the oma consts from the headers. The full updated patchset is included. Maxim Poliakovski (1): mpeg: add experimental support for PSMF audio. Misty De Meo (5): oma: move some constants into libavcodec atrac3plus_parser: use libavcodec's oma Fix detecting ATRAC3 audio from MPS files mpeg: fix use of deprecated struct psmf: add FATE tests Changelog | 1 + libavcodec/Makefile | 1 + libavcodec/allcodecs.c| 1 + libavcodec/atrac3plus_parser.c| 153 ++ libavformat/oma.c => libavcodec/oma.h | 27 +++--- libavcodec/version.h | 2 +- libavformat/Makefile | 4 +- libavformat/mpeg.c| 15 libavformat/mpeg.h| 1 + libavformat/oma.h | 21 ++--- libavformat/omadec.c | 13 +-- libavformat/omaenc.c | 7 +- libavformat/version.h | 2 +- tests/Makefile| 1 + tests/fate/psmf.mak | 23 + 15 files changed, 233 insertions(+), 39 deletions(-) create mode 100644 libavcodec/atrac3plus_parser.c rename libavformat/oma.c => libavcodec/oma.h (65%) create mode 100644 tests/fate/psmf.mak -- 2.15.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] mpeg: add experimental support for PSMF audio.
From: Maxim Poliakovski
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/atrac3plus_parser.c | 153 +
libavformat/mpeg.c | 27 +++-
4 files changed, 181 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/atrac3plus_parser.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ca72138c02..e0e3f1ebac 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -977,6 +977,7 @@ OBJS-$(CONFIG_AAC_PARSER) += aac_parser.o
aac_ac3_parser.o \
mpeg4audio.o
OBJS-$(CONFIG_AC3_PARSER) += ac3tab.o aac_ac3_parser.o
OBJS-$(CONFIG_ADX_PARSER) += adx_parser.o adx.o
+OBJS-$(CONFIG_ATRAC3P_PARSER) += atrac3plus_parser.o
OBJS-$(CONFIG_BMP_PARSER) += bmp_parser.o
OBJS-$(CONFIG_CAVSVIDEO_PARSER)+= cavs_parser.o
OBJS-$(CONFIG_COOK_PARSER) += cook_parser.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ed1e7ab06e..81d5d2814a 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -623,6 +623,7 @@ static void register_all(void)
REGISTER_PARSER(AAC_LATM, aac_latm);
REGISTER_PARSER(AC3,ac3);
REGISTER_PARSER(ADX,adx);
+REGISTER_PARSER(ATRAC3P,atrac3p);
REGISTER_PARSER(BMP,bmp);
REGISTER_PARSER(CAVSVIDEO, cavsvideo);
REGISTER_PARSER(COOK, cook);
diff --git a/libavcodec/atrac3plus_parser.c b/libavcodec/atrac3plus_parser.c
new file mode 100644
index 00..01fcad4c45
--- /dev/null
+++ b/libavcodec/atrac3plus_parser.c
@@ -0,0 +1,153 @@
+/*
+ * Copyright (C) 2014 Maxim Poliakovski
+ *
+ * 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 "parser.h"
+#include "get_bits.h"
+#include "libavformat/oma.h"
+
+typedef struct Atrac3PlusParseContext {
+ParseContext pc;
+uint8_t hdr[8];
+int hdr_bytes_needed, got_bytes;
+int sample_rate, channel_id, frame_size;
+} Atrac3PlusParseContext;
+
+static int parse_sound_frame_header(Atrac3PlusParseContext *c,
+const uint8_t *buf)
+{
+uint16_t atrac_config;
+
+if (AV_RB16(buf) != 0x0FD0)
+return AVERROR_INVALIDDATA;
+
+atrac_config = AV_RB16(&buf[2]);
+c->sample_rate = ff_oma_srate_tab[(atrac_config >> 13) & 7] * 100;
+c->channel_id = (atrac_config >> 10) & 7;
+c->frame_size = ((atrac_config & 0x3FF) * 8) + 8;
+
+if (!c->channel_id || !c->sample_rate || !c->frame_size)
+return AVERROR_INVALIDDATA;
+
+return 0;
+}
+
+static int ff_atrac3p_parse(AVCodecParserContext *s,
+ AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+Atrac3PlusParseContext *ctx = s->priv_data;
+const uint8_t *hdr_buf = buf;
+size_t bytes_remain;
+int frame_size, hdr_bytes = 8;
+int next = 0;
+
+if (s->flags & PARSER_FLAG_COMPLETE_FRAMES || !buf_size) {
+next = buf_size;
+} else {
+if (buf_size >= 2) {
+bytes_remain = AV_RB16(buf);
+
+if (bytes_remain != 0xFD0) {
+next += 2;
+buf += 2;
+buf_size -= 2;
+hdr_buf = buf;
+
+if (bytes_remain && !ctx->pc.index && !ctx->hdr_bytes_needed) {
+av_log(avctx, AV_LOG_ERROR,
+ "2nd frame portion found but the 1st one is
missing!\n");
+return AVERROR_INVALIDDATA;
+}
+
+if (ctx->hdr_bytes_needed) {
+if (buf_size >= ctx->hdr_bytes_needed) {
+memcpy(&ctx->hdr[8 - ctx->hdr_bytes_needed],
+ buf, ctx->hdr_bytes_needed);
+hdr_bytes = ctx->hdr_bytes_needed;
+ctx->hdr_bytes_needed = 0;
+hdr_buf = ctx->hdr;
+}
+} else if (bytes_remain) {
+if (buf_size < bytes_remain) {
+av_log(avctx, AV_LOG_ERROR,
+
[FFmpeg-devel] [PATCH 5/6] mpeg: fix use of deprecated struct
From: Misty De Meo
---
libavformat/mpeg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index a366ece0ed..210424faf3 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -547,8 +547,8 @@ redo:
len--;
for (i = 0; i < s->nb_streams; i++) {
st = s->streams[i];
-if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
-st->codec->codec_id == AV_CODEC_ID_ATRAC3P &&
+if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
+st->codecpar->codec_id == AV_CODEC_ID_ATRAC3P &&
st->id - 0x1BD0 == (startcode & 0xF))
goto found;
}
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/6] psmf: add FATE tests
From: Misty De Meo --- tests/Makefile | 1 + tests/fate/psmf.mak | 23 +++ 2 files changed, 24 insertions(+) create mode 100644 tests/fate/psmf.mak diff --git a/tests/Makefile b/tests/Makefile index fd3713fe81..c569091fcb 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -165,6 +165,7 @@ include $(SRC_PATH)/tests/fate/pcm.mak include $(SRC_PATH)/tests/fate/pixlet.mak include $(SRC_PATH)/tests/fate/probe.mak include $(SRC_PATH)/tests/fate/prores.mak +include $(SRC_PATH)/tests/fate/psmf.mak include $(SRC_PATH)/tests/fate/qt.mak include $(SRC_PATH)/tests/fate/qtrle.mak include $(SRC_PATH)/tests/fate/real.mak diff --git a/tests/fate/psmf.mak b/tests/fate/psmf.mak new file mode 100644 index 00..0d83daad49 --- /dev/null +++ b/tests/fate/psmf.mak @@ -0,0 +1,23 @@ +# +# Test detecting ATRAC-3 audio in Sony MPEG files +# + +PROBE_CODEC_NAME_COMMAND = \ + ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream=codec_name \ + -select_streams a -print_format default=noprint_wrappers=1 -bitexact -v 0 + +FATE_PSMF_FFPROBE = fate-psmf-probe-6 \ + fate-psmf-probe-EV01_01_0500D + +fate-psmf-probe-6: SRC = $(TARGET_SAMPLES)/psmf/6.MPS +fate-psmf-probe-6: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)" +fate-psmf-probe-6: CMP = oneline +fate-psmf-probe-6: REF = codec_name=atrac3p +fate-psmf-probe-EV01_01_0500D: SRC = $(TARGET_SAMPLES)/psmf/EV01_01_0500D.PMF +fate-psmf-probe-EV01_01_0500D: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)" +fate-psmf-probe-EV01_01_0500D: CMP = oneline +fate-psmf-probe-EV01_01_0500D: REF = codec_name=atrac3p + +FATE_SAMPLES_FFPROBE += $(FATE_PSMF_FFPROBE) + +fate-psmf: $(FATE_PSMF_FFPROBE) -- 2.15.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers
On Sun, Dec 24, 2017 at 05:50:29PM +0100, wm4 wrote:
> On Sun, 24 Dec 2017 12:43:27 +0100
> Michael Niedermayer wrote:
>
> > On Sun, Dec 24, 2017 at 02:31:16AM +0100, wm4 wrote:
> > > On Sun, 24 Dec 2017 02:06:40 +0100
> > > Michael Niedermayer wrote:
[...]
> >
> > > - also, we would have to provide stable/public API for implementing
> > > codecs in the first place (all AVCodec callback fields are private),
> > > and we're nowhere near the state of adding it
> >
> > I would love to see such a API and i would certainly contribute but
>
> > as explained above, we dont have it and we dont really need it for
> > registering user codec to be usefull in practice IMO
>
> Are you seriously arguing for API users to access internal API?
no. iam not arguing that anyone who has the choice should use internal
API.
[...]
>
> > There are more usecases. For example codec optimizations for niche
> > codecs where rejected on ffmpeg-devel.
> > I find it unfriendly from us if we reject improvments because they
> > arent in a area most of us care and then also drop the possibility
> > for externally maintaining and registering code without doing a
> > full fork (which is much more work to maintain)
>
> What? We accept tons of obscure features and optimizations.
>
> The only thing I remember that got consistently rejected were the HEVC
> optimizations - not because we didn't want them, but because they used
> intrinsics in x86 (instead of external asm), which we reject on
> principle. We (apparently) had bad experiences with them in the past,
> compiler support tends to be flaky, and performance of the generated
> code can depend much on used compiler and is not very predictable. You
> know very well that we have a policy to reject intrinsics and that we
> follow it for good reasons.
>
> I'm not sure why you feel the need to distort the facts that much just
> to make some sort of passive aggressive sounding point about general
> dev/project practices.
What is distorted ?
The case i was thinking of and refered to should be this thread:
"[FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on
the scenario, by supporting multiple output pixel formats."
The patch was as i said rejected
It was about a niche codec (cinepak)
It was an optimization as stated.
The rest of my statment was just what i find unfriendly, that is just
my oppinon.
Maybe that sounds "passive aggressive" i dont know, but then any self critique
could likely sound "passive aggressive" to someone
>
> > >
> > > > > +AVCodec *av_codec_next(const AVCodec *c)
> > > > > +{
> > > > > +pthread_once(&av_codec_next_init, av_codec_init_next);
> > > > > +
> > > > > +if (c)
> > > > > +return c->next;
> > > >
> > > > AVCodec->next should be removed as it makes the structs non constant
> > >
> > > That has to happen after a deprecation phase, unless you have an idea
> > > how to make av_codec_next() not O(n^2) without this.
> >
> > That can be done and there are many ways. Not saying we want to do it
> > first possibility, one can add a int "constant" to each AVCodec.
> > configure would have to choose these or there would be holes in the array.
>
> That sounds complicated, how would configure modify each AVCodec struct
> (which are spread into hundreds of source files)?
It would generate a header with a list, enum or #define
the named identifers of that list would be used in the individual files
>
> > a hashtable with a mutex is an option too but that seems not worth the
> > complexity / work
> > the 3rd obvious option is to make "next" a pointer to a int which is
> > initialized in each codec to some static int. Which can then be set
> > to the array index, the main struct can then remain in read only memory
> > iam pretty sure there are many more options
>
> Not sure how these are better than just initializing the next pointer
> for now, until deprecation removes it.
It would allow the AVCodec to be in read only memory, not a major thing
at all, but thats one of the main advantages of removing the next pointer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hls: fix compiling error
fix --disable-network compipling error
Signed-off-by: Steven Liu
---
libavformat/hls.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f00e22dfef..51d83b7557 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -611,14 +611,16 @@ static void update_options(char **dest, const char *name,
void *src)
static int open_url_keepalive(AVFormatContext *s, AVIOContext **pb,
const char *url)
{
-int ret;
+int ret = 0;
URLContext *uc = ffio_geturlcontext(*pb);
av_assert0(uc);
(*pb)->eof_reached = 0;
+#if CONFIG_HTTP_PROTOCOL
ret = ff_http_do_new_request(uc, url);
if (ret < 0) {
ff_format_io_close(s, pb);
}
+#endif
return ret;
}
--
2.14.3 (Apple Git-98)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/opensrt: add Haivision Open SRT protocol
On 19-Dec-17 15:01, nablet developer wrote: On 13 Dec 2017, at 15:31, Nablet Developer wrote: The protocol is used by thousands of Haivision customers since 2013, in extremely sensitive medical, military and enterprise applications with FIPS compliant encryption requirements. Since April 2017, the protocol is Open Source and meanwhile >50 partners joined the SRT Alliance (srtalliance.org). GStreamer already integrated the protocol and VLC has already accepted the pull request for adding the SRT protocol to VLC. We see a dramatic adoption of the protocol in the market and a lot of our partners are asking us frequently on a ffmpeg integration. Nablet Developer (1): avformat/opensrt: add Haivision Open SRT protocol configure | 10 + doc/protocols.texi | 116 + libavformat/Makefile| 1 + libavformat/opensrt.c | 622 libavformat/protocols.c | 1 + 5 files changed, 750 insertions(+) create mode 100644 libavformat/opensrt.c -- 2.7.4 ping ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library
On Mon, 25 Dec 2017 02:12:38 + Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov > --- > doc/APIchanges | 5 + > libavresample/avresample.h | 30 +- > 2 files changed, 30 insertions(+), 5 deletions(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index df79758e86..96fad416d5 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -15,6 +15,11 @@ libavutil: 2017-10-21 > > API changes, most recent first: > > +2017-xx-xx - xxx - lavr 4.0.0 - avresample.h > + Deprecate the entire library. It was unmaintained and redundant > + as libswresample did everything it did better, faster, with more > + control and with a better, slightly higher level API. > + I don't strongly disagree with the wording and also with the "deprecation", and I think we should build avr by default instead. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
