Re: [FFmpeg-devel] [PATCH] avutil/opencl: don't include config.h
2015-01-09 5:54 GMT+08:00 Thilo Borgmann : > Am 08.01.15 17:43, schrieb James Almer: > > On 08/01/15 4:52 AM, Wei Gao wrote: > >> 2015-01-08 10:10 GMT+08:00 James Almer : > >> > >>> On 07/01/15 10:55 PM, Wei Gao wrote: > 2015-01-08 8:42 GMT+08:00 Michael Niedermayer : > > > On Wed, Jan 07, 2015 at 05:44:41PM -0300, James Almer wrote: > >> On 06/01/15 11:27 PM, Michael Niedermayer wrote: > >>> On Tue, Jan 06, 2015 at 01:56:01AM -0300, James Almer wrote: > It's not an installed header. Use libavutil/avconfig.h instead. > >>> > >>> assuming noone objects to this "hack" ... ugly but it should fix > the > >>> build so ok > >> > >> Yes, i agree it's kinda ugly. What about this instead? > > > > LGTM but i dont have opencl setup so havnt tested it > > > Hi > > diff --git a/libavutil/opencl.h b/libavutil/opencl.h > index 4655cba..0b7b8d4 100644 > --- a/libavutil/opencl.h > +++ b/libavutil/opencl.h > @@ -32,11 +32,10 @@ > #ifndef LIBAVUTIL_OPENCL_H > #define LIBAVUTIL_OPENCL_H > > -#include "config.h" > -#if HAVE_CL_CL_H > -#include > -#else > +#ifdef __APPLE__ > #include > +#else > +#include > #endif > #include > #include "dict.h" > just this patch right? I can test it, but I don't have apple platform. > >>> > >>> Yes. > >>> The CL_cl_h check in configure could also be removed alongside this > since > >>> it wouldn't > >>> be necessary anymore. > >>> > >> Hi > >> Thanks, so I merge the patch above then compile ffmpeg to test right? > >> I want to clear the way of testing. > >> > >> Thanks > >> Best regards > > > > Yes > > The patch works for me on OSX 10.10.1 > Compiled and tested (unsharp=7:7:2:opencl=1). > Hi The patch works for me on Mingw and Linux Thanks Best Regards > > -Thilo > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Adding Closed caption Support
On Sun, Jan 11, 2015 at 11:15:35PM +0100, Anshul Maheshwari wrote:
> ffmpeg | branch: master | Anshul Maheshwari | Tue
> Jan 6 12:41:34 2015 +0530| [4b6262610bd516320b3fca71ef03ff9bf1aa5066] |
> committer: Michael Niedermayer
>
> Adding Closed caption Support
>
> Signed-off-by: Anshul Maheshwari
>
> To test Closed caption use following command
> ffmpeg -f lavfi -i "movie=input.ts[out0+subcc]" -map s output.srt
> Signed-off-by: Michael Niedermayer
Sorry for the late review, I wasn't available.
Q: how does it compare to libzvbi, do we still need libzvbi (especially
the text part)?
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4b6262610bd516320b3fca71ef03ff9bf1aa5066
> ---
>
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c|1 +
> libavcodec/ccaption_dec.c | 529
> +
> 3 files changed, 531 insertions(+)
>
Where is the FATE test for this?
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 6b85420..80ee389 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -173,6 +173,7 @@ OBJS-$(CONFIG_BRENDER_PIX_DECODER) += brenderpix.o
> OBJS-$(CONFIG_C93_DECODER) += c93.o
> OBJS-$(CONFIG_CAVS_DECODER)+= cavs.o cavsdec.o cavsdsp.o \
>cavsdata.o mpeg12data.o
> +OBJS-$(CONFIG_CCAPTION_DECODER)+= ccaption_dec.o
> OBJS-$(CONFIG_CDGRAPHICS_DECODER) += cdgraphics.o
> OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o
> OBJS-$(CONFIG_CINEPAK_DECODER) += cinepak.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 512711e..29b45f3 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -481,6 +481,7 @@ void avcodec_register_all(void)
> /* subtitles */
> REGISTER_ENCDEC (SSA, ssa);
> REGISTER_ENCDEC (ASS, ass);
> +REGISTER_DECODER(CCAPTION, ccaption);
> REGISTER_ENCDEC (DVBSUB,dvbsub);
> REGISTER_ENCDEC (DVDSUB,dvdsub);
> REGISTER_DECODER(JACOSUB, jacosub);
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> new file mode 100644
> index 000..a92c609
> --- /dev/null
> +++ b/libavcodec/ccaption_dec.c
> @@ -0,0 +1,529 @@
> +/*
> + * Closed Caption Decoding
> + * Copyright (c) 2015 Anshul Maheshwari
> + *
> + * 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 "avcodec.h"
> +#include "ass.h"
> +#include "libavutil/opt.h"
> +
> +#define CHAR_DEBUG
We have av_dlog() for that purpose.
> +#define SCREEN_ROWS 15
> +#define SCREEN_COLUMNS 32
> +
> +#define SET_FLAG(var, val) ( var |= ( 1 << (val) ) )
> +#define UNSET_FLAG(var, val) ( var &= ~( 1 << (val)) )
> +#define CHECK_FLAG(var, val) ( (var) & (1 << (val) ) )
> +
> +/*
> + * TODO list
> + * 1) handle font and color completely
> + */
> +enum cc_mode {
> +CCMODE_POPON,
> +CCMODE_PAINTON,
> +CCMODE_ROLLUP_2,
> +CCMODE_ROLLUP_3,
> +CCMODE_ROLLUP_4,
> +CCMODE_TEXT,
> +};
> +
> +enum cc_color_code
> +{
The style is broken all over the file, but please at least make it
consistent with the surrounding one.
> +CCCOL_WHITE,
> +CCCOL_GREEN,
> +CCCOL_BLUE,
> +CCCOL_CYAN,
> +CCCOL_RED,
> +CCCOL_YELLOW,
> +CCCOL_MAGENTA,
> +CCCOL_USERDEFINED,
> +CCCOL_BLACK,
> +CCCOL_TRANSPARENT
note: you should keep a trailing comma at the end of such structure to
reduce later diffs.
> +};
> +
> +enum cc_font
> +{
> +CCFONT_REGULAR,
> +CCFONT_ITALICS,
> +CCFONT_UNDERLINED,
> +CCFONT_UNDERLINED_ITALICS
> +};
> +
> +static const unsigned char pac2_attribs[][3] = // Color, font, ident
> +{
> +{ CCCOL_WHITE, CCFONT_REGULAR, 0 }, // 0x40 || 0x60
> +{ CCCOL_WHITE, CCFONT_UNDERLINED, 0 }, // 0x41 || 0x61
> +{ CCCOL_GREEN, CCFONT_REGULAR, 0 }, // 0x42 || 0x62
> +{ CCCOL_GREEN, CCFONT_UNDERLINED, 0 }, // 0x43 || 0x63
> +{ CCCOL_BLUE, CCFONT_REGULAR, 0 }, // 0x44 || 0x64
> +{ CCCOL_BLUE, CCFONT_UNDERLINED, 0 }, // 0x45 || 0x65
> +{ CCCOL_CYAN, CCFONT_REGULAR, 0 }, // 0x46 || 0x66
> +{ CCCOL_CYAN, CCFONT_UNDERLINED, 0 }, // 0x47 || 0x67
> +{ CCCOL_RED, C
Re: [FFmpeg-devel] SCTE-35 development
On 01/12/2015 02:48 AM, Michael Niedermayer wrote: > On Mon, Jan 12, 2015 at 01:09:11AM +0530, Anshul wrote: >> On 12/31/2014 07:13 PM, Michael Niedermayer wrote: >>> So SCTE-35 is basically about segmenting a video timewise (primarely >>> to mark Ads but not always) We already have a API to segment videos >>> timewise, its AVFormatContext.chapters that may need some changes to >>> handle incrementally added (and on the muxer side incrementally >>> stored) data or we might even choose a different system entirely than >>> that AVChapter array for such incrementally stored segments but i dont >>> think data decoders with a completely opaque input and output are a >>> reasonable API for communicating such temporal segmenting [...] >> I have not looked at it yet, due to some disadvantage told me on irc, >> sry but I have forgotten those disadvantage of chapters. > It would be better if the reasons behind a design decission are > understood and documented > Yes, I studied the document of AVChapter, just now its only used for mostly header and sometimes trailer. Its structure match very much to interface of scte_35, but it is not sufficient I have to have locking mechanism there, so that I would know whether I am still using it or not. These chapters also look very static, I did not find any logic to cancel the event at last moment. modification to my previous patch were possible with AVChapter, but now I feel i don't require to communicate from demuxer or decoder, because I have written a parser in AVFormat and only used in hls muxer. and If later I would use that parser in filter, ubitux gave me idea to use ff_ap >> if any one here still believe that chapters approach will be better, I >> will look at it. >> >> Though I have done some new implementation, it is out of avcodec folder. >> I have tweaked slightly AVFormat public structure. >> >> for details please review attached draft patch. >> >> I would appreciate, if someone pinpoint architecture issue first. >> I really get demoralized when I have to throw all my work after >> considering all review comments. >> then at last some architecture comments. >> >> lots of memory leakage are still there, please ignore it for time being, >> i am working on it. >> >> follwing is the command which is also added in commit message to use >> this patch >> ./ffmpeg_g -vsync 0 -copyts -i ~/test_videos/mpegwithscte35.ts >> -hls_list_size 1000 -dcodec copy tmp/some.m3u8 >> >> -Anshul >> ffmpeg.c|6 +- >> ffmpeg_opt.c| 10 ++ >> libavcodec/avcodec.h|1 + >> libavcodec/codec_desc.c |6 ++ >> libavformat/Makefile|1 + >> libavformat/avformat.h | 17 + >> libavformat/format.c|2 ++ >> libavformat/hlsenc.c| 39 +++ >> libavformat/mpegts.c| 45 +++-- >> libavformat/utils.c |1 + > theres some file missing > libavformat/hlsenc.c:39:21: fatal error: scte_35.h: No such file or directory I always forget this if I don't check the ffmpeg codec checklist. hope i will gradually get into this habit. and I am sorry for being so annoying to all. attached new patch. -Anshul >From 4c0e25ea5827b03b61d2a49eee287515d7dc031d Mon Sep 17 00:00:00 2001 From: Anshul Maheshwari Date: Mon, 12 Jan 2015 17:40:10 +0530 Subject: [PATCH] Adding SCTE 35 implementation in avformat Use following cmd to test it. ./ffmpeg -vsync 0 -copyts -i ~/test_videos/mpegwithscte35.ts -hls_list_size 1000 -dcodec copy tmp/some.m3u8 --- ffmpeg.c| 6 +- ffmpeg_opt.c| 10 ++ libavcodec/avcodec.h| 1 + libavcodec/codec_desc.c | 6 + libavformat/Makefile| 1 + libavformat/avformat.h | 17 +++ libavformat/format.c| 2 + libavformat/hlsenc.c| 39 +- libavformat/mpegts.c| 45 ++- libavformat/scte_35.c | 348 libavformat/scte_35.h | 48 +++ libavformat/utils.c | 1 + 12 files changed, 513 insertions(+), 11 deletions(-) create mode 100644 libavformat/scte_35.c create mode 100644 libavformat/scte_35.h diff --git a/ffmpeg.c b/ffmpeg.c index ddf4272..a7f078b 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -60,6 +60,7 @@ #include "libavutil/bprint.h" #include "libavutil/time.h" #include "libavutil/threadmessage.h" +#include "libavutil/buffer_internal.h" #include "libavformat/os_support.h" #include "libavformat/ffm.h" // not public API @@ -2907,6 +2908,8 @@ static int transcode_init(void) enc_ctx->height= input_streams[ost->source_index]->st->codec->height; } break; +case AVMEDIA_TYPE_DATA: +break; default: abort(); break; @@ -3464,7 +3467,8 @@ static int process_input(int file_index) OutputStream *ost = output_streams[j]; if (ost->source_
Re: [FFmpeg-devel] SCTE-35 development
On 01/12/2015 05:59 PM, Anshul wrote: > On 01/12/2015 02:48 AM, Michael Niedermayer wrote: >> On Mon, Jan 12, 2015 at 01:09:11AM +0530, Anshul wrote: >>> On 12/31/2014 07:13 PM, Michael Niedermayer wrote: So SCTE-35 is basically about segmenting a video timewise (primarely to mark Ads but not always) We already have a API to segment videos timewise, its AVFormatContext.chapters that may need some changes to handle incrementally added (and on the muxer side incrementally stored) data or we might even choose a different system entirely than that AVChapter array for such incrementally stored segments but i dont think data decoders with a completely opaque input and output are a reasonable API for communicating such temporal segmenting [...] >>> I have not looked at it yet, due to some disadvantage told me on irc, >>> sry but I have forgotten those disadvantage of chapters. >> It would be better if the reasons behind a design decission are >> understood and documented >> > Yes, I studied the document of AVChapter, just now its only used > for mostly header and sometimes trailer. > Its structure match very much to interface of scte_35, but it is not > sufficient > I have to have locking mechanism there, so that I would know whether I > am still > using it or not. > These chapters also look very static, I did not find any logic to cancel > the event > at last moment. > > modification to my previous patch were possible with AVChapter, but now > I feel > i don't require to communicate from demuxer or decoder, because I have > written a > parser in AVFormat and only used in hls muxer. > and If later I would use that parser in filter, ubitux gave me idea to > use ff_ap > >>> if any one here still believe that chapters approach will be better, I >>> will look at it. >>> >>> Though I have done some new implementation, it is out of avcodec folder. >>> I have tweaked slightly AVFormat public structure. >>> >>> for details please review attached draft patch. >>> >>> I would appreciate, if someone pinpoint architecture issue first. >>> I really get demoralized when I have to throw all my work after >>> considering all review comments. >>> then at last some architecture comments. >>> >>> lots of memory leakage are still there, please ignore it for time being, >>> i am working on it. >>> >>> follwing is the command which is also added in commit message to use >>> this patch >>> ./ffmpeg_g -vsync 0 -copyts -i ~/test_videos/mpegwithscte35.ts >>> -hls_list_size 1000 -dcodec copy tmp/some.m3u8 >>> >>> -Anshul >>> ffmpeg.c|6 +- >>> ffmpeg_opt.c| 10 ++ >>> libavcodec/avcodec.h|1 + >>> libavcodec/codec_desc.c |6 ++ >>> libavformat/Makefile|1 + >>> libavformat/avformat.h | 17 + >>> libavformat/format.c|2 ++ >>> libavformat/hlsenc.c| 39 +++ >>> libavformat/mpegts.c| 45 >>> +++-- >>> libavformat/utils.c |1 + >> theres some file missing >> libavformat/hlsenc.c:39:21: fatal error: scte_35.h: No such file or directory > I always forget this if I don't check the ffmpeg codec checklist. > hope i will gradually get into this habit. > and I am sorry for being so annoying to all. > > attached new patch. > -Anshul > forgot to signoff. attached another -Anshul >From 1933bbcea6a3370d62f4dd188b3de592874255c8 Mon Sep 17 00:00:00 2001 From: Anshul Maheshwari Date: Mon, 12 Jan 2015 18:24:59 +0530 Subject: [PATCH] Adding SCTE 35 implementation in avformat Signed-off-by: Anshul Maheshwari Use following cmd to test it. ./ffmpeg -vsync 0 -copyts -i ~/test_videos/mpegwithscte35.ts -hls_list_size 1000 -dcodec copy tmp/some.m3u8 --- ffmpeg.c| 6 +- ffmpeg_opt.c| 10 ++ libavcodec/avcodec.h| 1 + libavcodec/codec_desc.c | 6 + libavformat/Makefile| 1 + libavformat/avformat.h | 17 +++ libavformat/format.c| 2 + libavformat/hlsenc.c| 39 +- libavformat/mpegts.c| 45 ++- libavformat/scte_35.c | 348 libavformat/scte_35.h | 48 +++ libavformat/utils.c | 1 + 12 files changed, 513 insertions(+), 11 deletions(-) create mode 100644 libavformat/scte_35.c create mode 100644 libavformat/scte_35.h diff --git a/ffmpeg.c b/ffmpeg.c index ddf4272..a7f078b 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -60,6 +60,7 @@ #include "libavutil/bprint.h" #include "libavutil/time.h" #include "libavutil/threadmessage.h" +#include "libavutil/buffer_internal.h" #include "libavformat/os_support.h" #include "libavformat/ffm.h" // not public API @@ -2907,6 +2908,8 @@ static int transcode_init(void) enc_ctx->height= input_streams[ost->source_index]->st->codec->height; } break; +case AVMEDIA_TYPE_DATA: +break;
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
Hi, On Mon, Jan 12, 2015 at 12:59 AM, Zhao, Halley wrote: > I understand you concern. > The wrapper doesn't help much to ffmpeg itself, however, it benefits much > to the apps uses ffmpeg, to pick up hw capability for codec. So specifically, what are the features that you get with yaml that ffmpeg doesn't already provide (that is: yaml is itself just a wrapper for other stuff; what does it wrap that ffmpeg doesn't have already?). I see h264enc/vp8dec/vp8enc/vp9dec/jpegdec/jpegenc vaapi. Anything else? Why not just implement these in ffmpeg directly? (Note that indeed, we did not link to libvpx to get vp9/vp8 decoding; we wrote our own, and it worked _much_ better. That same may be true here also.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
On Mon, 12 Jan 2015 08:24:35 -0500 "Ronald S. Bultje" wrote: > Hi, > > On Mon, Jan 12, 2015 at 12:59 AM, Zhao, Halley > wrote: > > > I understand you concern. > > The wrapper doesn't help much to ffmpeg itself, however, it benefits much > > to the apps uses ffmpeg, to pick up hw capability for codec. > > > So specifically, what are the features that you get with yaml that ffmpeg > doesn't already provide (that is: yaml is itself just a wrapper for other > stuff; what does it wrap that ffmpeg doesn't have already?). I see > h264enc/vp8dec/vp8enc/vp9dec/jpegdec/jpegenc vaapi. Anything else? Why not > just implement these in ffmpeg directly? >From what I can see: - libyami doesn't require the relatively terrible boilerplate for hwaccel (creating the hw decoder yourself, maintaining a surface pool, etc.), making this lib very attractive for those who want something simple, and who possibly don't even want to depend on ffmpeg - uses some new APIs (not supported by all drivers yet), which work around vaapi suckage, such as requiring a shared context. Namely, the dma_buf stuff. I wonder how well the latter actually works... > (Note that indeed, we did not link to libvpx to get vp9/vp8 decoding; we > wrote our own, and it worked _much_ better. That same may be true here > also.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
Hi, On Mon, Jan 12, 2015 at 9:04 AM, wm4 wrote: > On Mon, 12 Jan 2015 08:24:35 -0500 > "Ronald S. Bultje" wrote: > > > Hi, > > > > On Mon, Jan 12, 2015 at 12:59 AM, Zhao, Halley > > wrote: > > > > > I understand you concern. > > > The wrapper doesn't help much to ffmpeg itself, however, it benefits > much > > > to the apps uses ffmpeg, to pick up hw capability for codec. > > > > > > So specifically, what are the features that you get with yaml that ffmpeg > > doesn't already provide (that is: yaml is itself just a wrapper for other > > stuff; what does it wrap that ffmpeg doesn't have already?). I see > > h264enc/vp8dec/vp8enc/vp9dec/jpegdec/jpegenc vaapi. Anything else? Why > not > > just implement these in ffmpeg directly? > > From what I can see: > > - libyami doesn't require the relatively terrible boilerplate for > hwaccel (creating the hw decoder yourself, maintaining a surface > pool, etc.), making this lib very attractive for those who want > something simple, and who possibly don't even want to depend on ffmpeg > - uses some new APIs (not supported by all drivers yet), which work > around vaapi suckage, such as requiring a shared context. Namely, the > dma_buf stuff. > > I wonder how well the latter actually works... So I don't know if anyone remembers me ranting about libxyz suckage, but yami sounds a lot like xyz. So: what are the chances that five years down the line, this lib ends up being unmaintained, having security issues, portability issues etc., and us basically just being stuck with yet another xyz that doesn't really solve our issue so we have to re-do it internally anyway a few years down the line, wishing we had done so a few years earlier? There's examples of good xyzs, e.g. x264 is a most wonderful software project; there's also examples of (imo) fails, such as librtmp. What guarantees do we have that yami is a good xyz? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
On Mon, 12 Jan 2015 00:46:26 + "Zhao, Halley" wrote: > > Maintaining decoders is the point of this project. > Yes, I agree the core of ffmpeg is codec; > But, from the user, ffmpeg is usually treated as a light-weight media > framework. Being a media framework, it is good to leverage hw codec > in many cases. i just want to make clear that wm4 is but one of the many devels in ffmpeg and please dont let any one dev scare you off from contributing. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
On Mon, 12 Jan 2015 08:24:35 -0500 "Ronald S. Bultje" wrote: > Anything else? Why not just implement these in ffmpeg directly? because (i'm guessing) they are developing libyami with other projects, not ffmpeg. i know everyone wants to reinvent the wheels here, but also that may have a detrimental effect on development if nothing gets in except ffmpeg-style-wheels. i'm not sure how useful the codec wrapper will be, but it does have features we dont yet. if no one wants these libs , i'm not going to push the issue. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
On Mon, 12 Jan 2015 10:07:56 -0500 compn wrote: > On Mon, 12 Jan 2015 08:24:35 -0500 > "Ronald S. Bultje" wrote: > > > Anything else? Why not just implement these in ffmpeg directly? > > because (i'm guessing) they are developing libyami with other projects, > not ffmpeg. > > i know everyone wants to reinvent the wheels here, but also that may > have a detrimental effect on development if nothing gets in except > ffmpeg-style-wheels. > > i'm not sure how useful the codec wrapper will be, but it does have > features we dont yet. if no one wants these libs , i'm not going to > push the issue. How about the fact that libyami reinvented the wheel long after ffmpeg? Look at all those codec parsers they have. There are many things that seem to stink about this lib. Having a C++ API is my least favorite one. So I guess I can say that in my opinion, the ffmpeg native support should be improved, instead of duplicating functionality all over the place. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
Hi, On Mon, Jan 12, 2015 at 10:07 AM, compn wrote: > On Mon, 12 Jan 2015 08:24:35 -0500 > "Ronald S. Bultje" wrote: > > > Anything else? Why not just implement these in ffmpeg directly? > > because (i'm guessing) they are developing libyami with other projects, > not ffmpeg. > > i know everyone wants to reinvent the wheels here, but also that may > have a detrimental effect on development if nothing gets in except > ffmpeg-style-wheels. These are two extremes: every single C function should be shareable between any two random software projects, or we should have no dependencies at all. In the real world, we balance these extremes by the practical implications (benefits vs. risks) associated with it. - too big dependency tree (how long does it take you to build gnome? I know users don't care, but what if you're a dev? I'm a dev) - are talented developers likely to maintain the alternate codebase (as opposed to a hypothetical impl in our tree)? - are talented (app) developers likely to use ffmpeg if we use a lib's implementation, rather than our own? - will they be around in 5 years? will they fix bugs? security issues? portability issues? will they care about ffmpeg-specific exposed bugs in their code? vs. - how long will it take us to implement these features ourselves? - are we the right people to take on long-term maintenance of such a feature? - are talented (app) developers interested in such features likely to use it if we directly provide it, as opposed to through some other lib (which is linked into ffmpeg)? - are talented developers likely to help us maintain the feature in our codebase as opposed to the impl in another lib? It's very complex. I don't have straight answers to all of these. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/opencl: don't include config.h
On 12/01/15 6:18 AM, Wei Gao wrote: > 2015-01-09 5:54 GMT+08:00 Thilo Borgmann : > >> Am 08.01.15 17:43, schrieb James Almer: >>> On 08/01/15 4:52 AM, Wei Gao wrote: 2015-01-08 10:10 GMT+08:00 James Almer : > On 07/01/15 10:55 PM, Wei Gao wrote: >> 2015-01-08 8:42 GMT+08:00 Michael Niedermayer : >> >>> On Wed, Jan 07, 2015 at 05:44:41PM -0300, James Almer wrote: On 06/01/15 11:27 PM, Michael Niedermayer wrote: > On Tue, Jan 06, 2015 at 01:56:01AM -0300, James Almer wrote: >> It's not an installed header. Use libavutil/avconfig.h instead. > > assuming noone objects to this "hack" ... ugly but it should fix >> the > build so ok Yes, i agree it's kinda ugly. What about this instead? >>> >>> LGTM but i dont have opencl setup so havnt tested it >>> >> Hi >> >> diff --git a/libavutil/opencl.h b/libavutil/opencl.h >> index 4655cba..0b7b8d4 100644 >> --- a/libavutil/opencl.h >> +++ b/libavutil/opencl.h >> @@ -32,11 +32,10 @@ >> #ifndef LIBAVUTIL_OPENCL_H >> #define LIBAVUTIL_OPENCL_H >> >> -#include "config.h" >> -#if HAVE_CL_CL_H >> -#include >> -#else >> +#ifdef __APPLE__ >> #include >> +#else >> +#include >> #endif >> #include >> #include "dict.h" >> just this patch right? I can test it, but I don't have apple platform. > > Yes. > The CL_cl_h check in configure could also be removed alongside this >> since > it wouldn't > be necessary anymore. > Hi Thanks, so I merge the patch above then compile ffmpeg to test right? I want to clear the way of testing. Thanks Best regards >>> >>> Yes >> >> The patch works for me on OSX 10.10.1 >> Compiled and tested (unsharp=7:7:2:opencl=1). >> > Hi > The patch works for me on Mingw and Linux > > Thanks > Best Regards > >> >> -Thilo Pushed, thanks to all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/swr: add SSE/AVX unpack_6ch functions
On Mon, Jan 12, 2015 at 04:18:15AM -0300, James Almer wrote: > int32/float only > > Signed-off-by: James Almer > --- > libswresample/x86/audio_convert.asm| 89 > ++ > libswresample/x86/audio_convert_init.c | 16 ++ > 2 files changed, 105 insertions(+) should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/mxfdec.c: read project_name metadata
On Sun, Jan 11, 2015 at 05:14:44PM -0800, Mark Reid wrote: > On Fri, Jan 9, 2015 at 7:47 PM, Michael Niedermayer > wrote: > > > On Mon, Jan 05, 2015 at 04:53:05PM -0800, Mark Reid wrote: > > > Hi, > > > MXF files generated by Media Composer or LibMXF can contain a > > > project name property in the Preface. Lots of existing samples have them. > > > > > > http://samples.ffmpeg.org/MXF/issue2160/PW0805A0V01.4C5B5636.EFA330.mxf > > > project_name: DNX145 PW Test > > > > > > > > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3450/WriteAvidMXFgenerated/5502_0010_v1.mxf > > > project_name: Rombus > > > > > > > > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3100/1sec_mxf_test_Video5270C795.mxf > > > project_name: NVB_DOOD > > > > > > i can also provide more samples if needed. > > > > > > --- > > > libavformat/mxfdec.c | 15 +++ > > > 1 file changed, 15 insertions(+) > > > > should i apply this patch? > > or is there some reason remaining not to ? > > the thread was kind of not ending with any clear conclusion and noone > > applied it ... > > > > [...] > > -- > > > > I assume everything was alright, only didn't get a sign off. The only > feedback I got, so far, was perhaps changing the metadata key to "title", > instead of "project_name", but we both agreed that the data is not the > title. patch applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] Support dynamic loading of third-party libs
Hi,
Attached is a preliminary patch that enables runtime loading of external
libraries via dlopen and friends. Dynamic loading is a build time option
(--enable-dynamic-loading) and if it is not activated the libs are
linked as usual (still no dependency to dlopen required).
The patch is intended as a basis for a discussion and therefore the
following applies:
- only libmp3lame and libva will by dynamically loaded atm
- only tested on linux atm
- deregistering not implemented (dlclose)
- versioning (which version of a lib should be loaded?)
- library usage counter missing
- ...?
What do you think?
Thanks,
Marc
diff --git a/configure b/configure
index 94f9432..5787101 100755
--- a/configure
+++ b/configure
@@ -101,6 +101,8 @@ Licensing options:
Configuration options:
--disable-static do not build static libraries [no]
--enable-shared build shared libraries [no]
+ --enable-dynamic-loading enable runtime detection of installed libraries
+ (disables compile time linking of third party libs)
--enable-small optimize for size instead of speed
--disable-runtime-cpudetect disable detecting cpu capabilities at runtime (smaller binary)
--enable-grayenable full grayscale support (slower color)
@@ -1079,6 +1081,15 @@ check_lib(){
check_header $header && check_func $func "$@" && add_extralibs "$@"
}
+check_ext_lib() {
+log check_ext_lib "$@"
+header="$1"
+func="$2"
+shift 2
+check_header $header && check_func $func "$@"
+enabled dynamic_loading || add_extralibs "$@"
+}
+
check_lib2(){
log check_lib2 "$@"
headers="$1"
@@ -1192,6 +1203,14 @@ require(){
check_lib $header $func "$@" || die "ERROR: $name not found"
}
+require_extlib(){
+name="$1"
+header="$2"
+func="$3"
+shift 3
+check_ext_lib $header $func "$@" || die "ERROR: $name not found"
+}
+
require2(){
name="$1"
headers="$2"
@@ -1432,6 +1451,7 @@ FEATURE_LIST="
small
static
swscale_alpha
+dynamic_loading
"
HWACCEL_LIST="
@@ -4855,6 +4875,10 @@ for func in $MATH_FUNCS; do
eval check_mathfunc $func \${${func}_args:-1}
done
+enabled dynamic_loading && { { check_lib2 "windows.h" LoadLibrary; } ||
+ { check_lib2 "dlfcn.h" dlopen -ldl; } ||
+ die "ERROR: LoadLibrary/dlopen not found for dynamic-loading"; }
+
# these are off by default, so fail if requested and not available
enabled avfoundation_indev && { check_header_oc AVFoundation/AVFoundation.h || disable avfoundation_indev; }
enabled avisynth && { { check_lib2 "windows.h" LoadLibrary; } ||
@@ -4887,7 +4911,7 @@ enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
done || die "ERROR: libgsm not found"; }
enabled libilbc && require libilbc ilbc.h WebRtcIlbcfix_InitDecode -lilbc
enabled libmodplug&& require_pkg_config libmodplug libmodplug/modplug.h ModPlug_Load
-enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame
+enabled libmp3lame&& require_extlib "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame
enabled libnut&& require libnut libnut.h nut_demuxer_init -lnut
enabled libopencore_amrnb && require libopencore_amrnb opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb
enabled libopencore_amrwb && require libopencore_amrwb opencore-amrwb/dec_if.h D_IF_init -lopencore-amrwb
@@ -5109,7 +5133,7 @@ int main(void) { IDirectXVideoDecoder *o = NULL; IDirectXVideoDecoder_Release(o)
EOF
enabled vaapi &&
-check_lib va/va.h vaInitialize -lva ||
+check_ext_lib va/va.h vaInitialize -lva ||
disable vaapi
enabled vdpau &&
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 99467bb..4928b20 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3228,7 +3228,7 @@ typedef struct AVCodec {
/**
* Initialize codec static data, called from avcodec_register().
*/
-void (*init_static_data)(struct AVCodec *codec);
+int (*init_static_data)(struct AVCodec *codec);
int (*init)(AVCodecContext *);
int (*encode_sub)(AVCodecContext *, uint8_t *buf, int buf_size,
@@ -3373,6 +3373,11 @@ typedef struct AVHWAccel {
void (*decode_mb)(struct MpegEncContext *s);
/**
+* Initialize codec static data, called from av_register_hwaccel().
+*/
+int (*init_static_data)(struct AVHWAccel *hwaccel);
+
+/**
* Initialize the hwaccel private data.
*
* This will be called from ff_get_format(), after hwaccel and
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index f4e12e8..fbfb8b8 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -45,6 +45,20 @@
# define STRIDE_ALIGN 8
#endif
+
+#if CONFIG_DYNAMIC_LOADING
+#define FUNC_DEF(struct_name, func_name) {#func_name, (void **)&struct_name.
Re: [FFmpeg-devel] [PATCH] x86/swr: add SSE/AVX unpack_6ch functions
On 12/01/15 1:55 PM, Michael Niedermayer wrote: > On Mon, Jan 12, 2015 at 04:18:15AM -0300, James Almer wrote: >> int32/float only >> >> Signed-off-by: James Almer >> --- >> libswresample/x86/audio_convert.asm| 89 >> ++ >> libswresample/x86/audio_convert_init.c | 16 ++ >> 2 files changed, 105 insertions(+) > > should be ok Pushed. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
On 09.01.2015, at 09:15, "Zhao, Halley" wrote: > From: "Zhao, Halley" > > - do not support multi-thread decoding, it is unnecessary for hw While it might not be possible to support in a proper way, and the FFmpeg multithreading is probably useless in the context of this library, but I think this is not generally true. Most hardware decoders need a good bit of parsing, and for some in combination with high-bitrate content it is enough that multithreading can be useful due to allowing to use two CPUs at low frequencies instead of having to clock one significantly higher. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Support dynamic loading of third-party libs
On Mon, Jan 12, 2015 at 06:59:33PM +0100, Marc Giger wrote: > Hi, > > Attached is a preliminary patch that enables runtime loading of external > libraries via dlopen and friends. Dynamic loading is a build time option > (--enable-dynamic-loading) and if it is not activated the libs are > linked as usual (still no dependency to dlopen required). > > The patch is intended as a basis for a discussion and therefore the > following applies: > > - only libmp3lame and libva will by dynamically loaded atm > - only tested on linux atm tested building 32bit binaries on 64bit linux: LD ffmpeg_g /usr/bin/ld: cannot find -lva collect2: ld returned 1 exit status make: *** [ffmpeg_g] Error 1 > - deregistering not implemented (dlclose) > - versioning (which version of a lib should be loaded?) > - library usage counter missing > - ...? > > What do you think? I think binary based distros (and some of their users) might like this feature as it would allow them to build packages which have fewer hard dependencies but can still use all the libs if they are available and installed about the code, i think it looks ugly, too many #if too many changes interspaced with existing code. Could this be implemeted in a nicer way ? I am thinking here of keeping (almost) all changes outside of existing files [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/platform: Add build instruction for Windows Runtime
Thank you for the feedback and suggestions Derek and Timothy. I didn't realize that MSYS2 is recommended over MinGW.org/MSYS. The current Platform Specific Information and the web links in the official FFmpeg documentation seem to suggest otherwise. Nevertheless, as MSYS2 is a better shell to build FFmpeg, I will update the instruction and upload them to the https://trac.ffmpeg.org/wiki/CompilationGuide wiki. Our goal is to provide a clear and trouble free instructions for developers with all level of proficiencies with Linux while trying to follow FFmpeg documentation standard and style. Therefore, we tend to be a little verbose to eliminate ambiguities in some areas. In term of the different architectures, each section (Windows Phone ARM, Windows Store, x86, etc) requires a different set of environment variables and compile/linking flags. Thus we thought presenting them in such format (looks like copy/paste) is the easier way for developer to digest. Any suggestion and feedback is greatly appreciated. Before uploading the instruction to the wiki, I will address the following items based on your feedback: 1. Update Windows Runtime Pre-requisite to use MSYS2 2. Replace MinGW section with MSYS2 accordingly Have we missed anything that you pointed out? Could you please clarify which unnecessary hack that you are referring to? Best Regards, Timotius Margo -Original Message- From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Derek Buitenhuis Sent: Saturday, January 10, 2015 10:18 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] doc/platform: Add build instruction for Windows Runtime On 1/10/2015 6:02 PM, Timothy Gu wrote: >> Almost whole patch is wrong (should use MSYS2), out of scope for >> FFmpeg, and uses the wrong title (we *do not* want MinGW here at >> all). Sure. My issue is that people confused MinGW (the toolchain) with MSYS (the environment, which is sometimes on mingw.org). > This is the best solution right now. Please add your information to > the wiki page https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT for > now, and after we think it is good to be merged into platforms.texi we > will do just that. That sounds good to me. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] libavformat/mxfdec.c: export the full UMID as metadata
On Fri, Jan 09, 2015 at 06:05:27PM -0800, Mark Reid wrote: > Changes since v1 > * changed umid text formating to conform to SMPTE330 > > --- > libavformat/mxfdec.c | 38 +++--- > 1 file changed, 31 insertions(+), 7 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Adding Closed caption Support
On 01/12/2015 04:16 PM, Clément Bœsch wrote:
On Sun, Jan 11, 2015 at 11:15:35PM +0100, Anshul Maheshwari wrote:
ffmpeg | branch: master | Anshul Maheshwari
| Tue Jan 6 12:41:34 2015 +0530|
[4b6262610bd516320b3fca71ef03ff9bf1aa5066] | committer: Michael
Niedermayer
Adding Closed caption Support
Signed-off-by: Anshul Maheshwari
To test Closed caption use following command
ffmpeg -f lavfi -i "movie=input.ts[out0+subcc]" -map s output.srt
Signed-off-by: Michael Niedermayer
Sorry for the late review, I wasn't available.
Q: how does it compare to libzvbi, do we still need libzvbi (especially
the text part)?
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4b6262610bd516320b3fca71ef03ff9bf1aa5066
---
libavcodec/Makefile |1 +
libavcodec/allcodecs.c|1 +
libavcodec/ccaption_dec.c | 529 +
3 files changed, 531 insertions(+)
Where is the FATE test for this?
will make it in week.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6b85420..80ee389 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -173,6 +173,7 @@ OBJS-$(CONFIG_BRENDER_PIX_DECODER) += brenderpix.o
OBJS-$(CONFIG_C93_DECODER) += c93.o
OBJS-$(CONFIG_CAVS_DECODER)+= cavs.o cavsdec.o cavsdsp.o \
cavsdata.o mpeg12data.o
+OBJS-$(CONFIG_CCAPTION_DECODER)+= ccaption_dec.o
OBJS-$(CONFIG_CDGRAPHICS_DECODER) += cdgraphics.o
OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o
OBJS-$(CONFIG_CINEPAK_DECODER) += cinepak.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 512711e..29b45f3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -481,6 +481,7 @@ void avcodec_register_all(void)
/* subtitles */
REGISTER_ENCDEC (SSA, ssa);
REGISTER_ENCDEC (ASS, ass);
+REGISTER_DECODER(CCAPTION, ccaption);
REGISTER_ENCDEC (DVBSUB,dvbsub);
REGISTER_ENCDEC (DVDSUB,dvdsub);
REGISTER_DECODER(JACOSUB, jacosub);
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
new file mode 100644
index 000..a92c609
--- /dev/null
+++ b/libavcodec/ccaption_dec.c
@@ -0,0 +1,529 @@
+/*
+ * Closed Caption Decoding
+ * Copyright (c) 2015 Anshul Maheshwari
+ *
+ * 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 "avcodec.h"
+#include "ass.h"
+#include "libavutil/opt.h"
+
+#define CHAR_DEBUG
We have av_dlog() for that purpose.
done
+#define SCREEN_ROWS 15
+#define SCREEN_COLUMNS 32
+
+#define SET_FLAG(var, val) ( var |= ( 1 << (val) ) )
+#define UNSET_FLAG(var, val) ( var &= ~( 1 << (val)) )
+#define CHECK_FLAG(var, val) ( (var) & (1 << (val) ) )
+
+/*
+ * TODO list
+ * 1) handle font and color completely
+ */
+enum cc_mode {
+CCMODE_POPON,
+CCMODE_PAINTON,
+CCMODE_ROLLUP_2,
+CCMODE_ROLLUP_3,
+CCMODE_ROLLUP_4,
+CCMODE_TEXT,
+};
+
+enum cc_color_code
+{
The style is broken all over the file, but please at least make it
consistent with the surrounding one.
done
+CCCOL_WHITE,
+CCCOL_GREEN,
+CCCOL_BLUE,
+CCCOL_CYAN,
+CCCOL_RED,
+CCCOL_YELLOW,
+CCCOL_MAGENTA,
+CCCOL_USERDEFINED,
+CCCOL_BLACK,
+CCCOL_TRANSPARENT
note: you should keep a trailing comma at the end of such structure to
reduce later diffs.
done
+};
+
+enum cc_font
+{
+CCFONT_REGULAR,
+CCFONT_ITALICS,
+CCFONT_UNDERLINED,
+CCFONT_UNDERLINED_ITALICS
+};
+
+static const unsigned char pac2_attribs[][3] = // Color, font, ident
+{
+{ CCCOL_WHITE, CCFONT_REGULAR, 0 }, // 0x40 || 0x60
+{ CCCOL_WHITE, CCFONT_UNDERLINED, 0 }, // 0x41 || 0x61
+{ CCCOL_GREEN, CCFONT_REGULAR, 0 }, // 0x42 || 0x62
+{ CCCOL_GREEN, CCFONT_UNDERLINED, 0 }, // 0x43 || 0x63
+{ CCCOL_BLUE, CCFONT_REGULAR, 0 }, // 0x44 || 0x64
+{ CCCOL_BLUE, CCFONT_UNDERLINED, 0 }, // 0x45 || 0x65
+{ CCCOL_CYAN, CCFONT_REGULAR, 0 }, // 0x46 || 0x66
+{ CCCOL_CYAN, CCFONT_UNDERLINED, 0 }, // 0x47 || 0x67
+{ CCCOL_RED, CCFONT_REGULAR, 0 }, // 0x48 || 0x68
+{ CCCOL_RED, CCFONT_UNDERLINED, 0 }, // 0x49 || 0x69
+{ CCCOL_YELLOW, CCFONT_REGULAR, 0 }, // 0x4a || 0x6a
+{ CCCOL_YELLOW,
Re: [FFmpeg-devel] [FFmpeg-cvslog] Adding Closed caption Support
On Tue, Jan 13, 2015 at 11:24 AM, Anshul Maheshwari wrote:
> On 01/12/2015 04:16 PM, Clément Bœsch wrote:
>
> On Sun, Jan 11, 2015 at 11:15:35PM +0100, Anshul Maheshwari wrote:
>
> ffmpeg | branch: master | Anshul Maheshwari | Tue
> Jan 6 12:41:34 2015 +0530| [4b6262610bd516320b3fca71ef03ff9bf1aa5066] |
> committer: Michael Niedermayer
>
> Adding Closed caption Support
>
> Signed-off-by: Anshul Maheshwari
>
> To test Closed caption use following command
> ffmpeg -f lavfi -i "movie=input.ts[out0+subcc]" -map s output.srt
> Signed-off-by: Michael Niedermayer
>
> Sorry for the late review, I wasn't available.
>
> Q: how does it compare to libzvbi, do we still need libzvbi (especially
> the text part)?
>
>
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4b6262610bd516320b3fca71ef03ff9bf1aa5066
>
> ---
>
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c|1 +
> libavcodec/ccaption_dec.c | 529
> +
> 3 files changed, 531 insertions(+)
>
>
> Where is the FATE test for this?
>
> will make it in week.
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 6b85420..80ee389 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -173,6 +173,7 @@ OBJS-$(CONFIG_BRENDER_PIX_DECODER) += brenderpix.o
> OBJS-$(CONFIG_C93_DECODER) += c93.o
> OBJS-$(CONFIG_CAVS_DECODER)+= cavs.o cavsdec.o cavsdsp.o \
>cavsdata.o mpeg12data.o
> +OBJS-$(CONFIG_CCAPTION_DECODER)+= ccaption_dec.o
> OBJS-$(CONFIG_CDGRAPHICS_DECODER) += cdgraphics.o
> OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o
> OBJS-$(CONFIG_CINEPAK_DECODER) += cinepak.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 512711e..29b45f3 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -481,6 +481,7 @@ void avcodec_register_all(void)
> /* subtitles */
> REGISTER_ENCDEC (SSA, ssa);
> REGISTER_ENCDEC (ASS, ass);
> +REGISTER_DECODER(CCAPTION, ccaption);
> REGISTER_ENCDEC (DVBSUB,dvbsub);
> REGISTER_ENCDEC (DVDSUB,dvdsub);
> REGISTER_DECODER(JACOSUB, jacosub);
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> new file mode 100644
> index 000..a92c609
> --- /dev/null
> +++ b/libavcodec/ccaption_dec.c
> @@ -0,0 +1,529 @@
> +/*
> + * Closed Caption Decoding
> + * Copyright (c) 2015 Anshul Maheshwari
> + *
> + * 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 "avcodec.h"
> +#include "ass.h"
> +#include "libavutil/opt.h"
> +
>
> +#define CHAR_DEBUG
>
> We have av_dlog() for that purpose.
>
> done
>
> +#define SCREEN_ROWS 15
> +#define SCREEN_COLUMNS 32
> +
> +#define SET_FLAG(var, val) ( var |= ( 1 << (val) ) )
> +#define UNSET_FLAG(var, val) ( var &= ~( 1 << (val)) )
> +#define CHECK_FLAG(var, val) ( (var) & (1 << (val) ) )
> +
> +/*
> + * TODO list
> + * 1) handle font and color completely
> + */
> +enum cc_mode {
> +CCMODE_POPON,
> +CCMODE_PAINTON,
> +CCMODE_ROLLUP_2,
> +CCMODE_ROLLUP_3,
> +CCMODE_ROLLUP_4,
> +CCMODE_TEXT,
> +};
> +
> +enum cc_color_code
> +{
>
> The style is broken all over the file, but please at least make it
> consistent with the surrounding one.
>
> done
>
> +CCCOL_WHITE,
> +CCCOL_GREEN,
> +CCCOL_BLUE,
> +CCCOL_CYAN,
> +CCCOL_RED,
> +CCCOL_YELLOW,
> +CCCOL_MAGENTA,
> +CCCOL_USERDEFINED,
> +CCCOL_BLACK,
> +CCCOL_TRANSPARENT
>
> note: you should keep a trailing comma at the end of such structure to
> reduce later diffs.
>
> done
>
> +};
> +
> +enum cc_font
> +{
> +CCFONT_REGULAR,
> +CCFONT_ITALICS,
> +CCFONT_UNDERLINED,
> +CCFONT_UNDERLINED_ITALICS
> +};
> +
> +static const unsigned char pac2_attribs[][3] = // Color, font, ident
> +{
> +{ CCCOL_WHITE, CCFONT_REGULAR, 0 }, // 0x40 || 0x60
> +{ CCCOL_WHITE, CCFONT_UNDERLINED, 0 }, // 0x41 || 0x61
> +{ CCCOL_GREEN, CCFONT_REGULAR, 0 }, // 0x42 || 0x62
> +{ CCCOL_GREEN, CCFONT_UNDERLINED, 0 }, // 0x43 || 0x63
> +{ CCCOL_BLUE, CCFONT_REGULAR, 0 }, // 0x44 || 0x64
> +
Re: [FFmpeg-devel] SCTE-35 development
On 01/12/2015 06:26 PM, Anshul wrote:
> On 01/12/2015 05:59 PM, Anshul wrote:
>> On 01/12/2015 02:48 AM, Michael Niedermayer wrote:
>>> On Mon, Jan 12, 2015 at 01:09:11AM +0530, Anshul wrote:
On 12/31/2014 07:13 PM, Michael Niedermayer wrote:
> So SCTE-35 is basically about segmenting a video timewise (primarely
> to mark Ads but not always) We already have a API to segment videos
> timewise, its AVFormatContext.chapters that may need some changes to
> handle incrementally added (and on the muxer side incrementally
> stored) data or we might even choose a different system entirely than
> that AVChapter array for such incrementally stored segments but i dont
> think data decoders with a completely opaque input and output are a
> reasonable API for communicating such temporal segmenting [...]
I have not looked at it yet, due to some disadvantage told me on irc,
sry but I have forgotten those disadvantage of chapters.
>>> It would be better if the reasons behind a design decission are
>>> understood and documented
>>>
>> Yes, I studied the document of AVChapter, just now its only used
>> for mostly header and sometimes trailer.
>> Its structure match very much to interface of scte_35, but it is not
>> sufficient
>> I have to have locking mechanism there, so that I would know whether I
>> am still
>> using it or not.
>> These chapters also look very static, I did not find any logic to cancel
>> the event
>> at last moment.
>>
>> modification to my previous patch were possible with AVChapter, but now
>> I feel
>> i don't require to communicate from demuxer or decoder, because I have
>> written a
>> parser in AVFormat and only used in hls muxer.
>> and If later I would use that parser in filter, ubitux gave me idea to
>> use ff_ap
>>
if any one here still believe that chapters approach will be better, I
will look at it.
Though I have done some new implementation, it is out of avcodec folder.
I have tweaked slightly AVFormat public structure.
for details please review attached draft patch.
I would appreciate, if someone pinpoint architecture issue first.
I really get demoralized when I have to throw all my work after
considering all review comments.
then at last some architecture comments.
lots of memory leakage are still there, please ignore it for time being,
i am working on it.
follwing is the command which is also added in commit message to use
this patch
./ffmpeg_g -vsync 0 -copyts -i ~/test_videos/mpegwithscte35.ts
-hls_list_size 1000 -dcodec copy tmp/some.m3u8
-Anshul
ffmpeg.c|6 +-
ffmpeg_opt.c| 10 ++
libavcodec/avcodec.h|1 +
libavcodec/codec_desc.c |6 ++
libavformat/Makefile|1 +
libavformat/avformat.h | 17 +
libavformat/format.c|2 ++
libavformat/hlsenc.c| 39 +++
libavformat/mpegts.c| 45
+++--
libavformat/utils.c |1 +
>>> theres some file missing
>>> libavformat/hlsenc.c:39:21: fatal error: scte_35.h: No such file or
>>> directory
>> I always forget this if I don't check the ffmpeg codec checklist.
>> hope i will gradually get into this habit.
>> and I am sorry for being so annoying to all.
>>
>> attached new patch.
>> -Anshul
>>
> forgot to signoff.
> attached another
>
> -Anshul
in that previous patch av_bprintf did not worked.
Attached another patch
-Anshul
>From 430b4d6061ade894b22cb7685a8b5d9af22b9c24 Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari
Date: Tue, 13 Jan 2015 11:53:32 +0530
Subject: [PATCH] Adding rollup functionality
Signed-off-by: Anshul Maheshwari
---
libavcodec/ccaption_dec.c | 222 +-
1 file changed, 140 insertions(+), 82 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index e05468f..debcc93 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -23,13 +23,12 @@
#include "ass.h"
#include "libavutil/opt.h"
-#define CHAR_DEBUG
#define SCREEN_ROWS 15
#define SCREEN_COLUMNS 32
-#define SET_FLAG(var, val) ( var |= ( 1 << (val) ) )
-#define UNSET_FLAG(var, val) ( var &= ~( 1 << (val)) )
-#define CHECK_FLAG(var, val) ( (var) & (1 << (val) ) )
+#define SET_FLAG(var, val) ( (var) |= ( 1 << (val)) )
+#define UNSET_FLAG(var, val) ( (var) &= ~( 1 << (val)) )
+#define CHECK_FLAG(var, val) ( (var) &( 1 << (val)) )
/*
* TODO list
@@ -44,8 +43,7 @@ enum cc_mode {
CCMODE_TEXT,
};
-enum cc_color_code
-{
+enum cc_color_code {
CCCOL_WHITE,
CCCOL_GREEN,
CCCOL_BLUE,
@@ -58,50 +56,50 @@ enum cc_color_code
CCCOL_TRANSPARENT,
};
-enum cc_font
-{
+enum cc_font {
CCFONT_REGULAR,
CCFONT_ITALICS,
CCFONT_UNDERLINED,
CCFONT_UNDER
Re: [FFmpeg-devel] [FFmpeg-cvslog] Adding Closed caption Support
On Tue, Jan 13, 2015 at 11:26:06AM +0530, Anshul Maheshwari wrote: [...] > > Also added roll-up functionality. > > > > patch is attached. > > Thanks > > Anshul > > > Attaching patch > From ca66e917f45bd47dd797930423d488fa9c781c4c Mon Sep 17 00:00:00 2001 > From: Anshul Maheshwari > Date: Mon, 12 Jan 2015 06:21:18 -0800 > Subject: [PATCH] Addig Rollup functionality > > Signed-off-by: Anshul Maheshwari > --- > libavcodec/ccaption_dec.c | 222 > +- > 1 file changed, 140 insertions(+), 82 deletions(-) > Please split your changes. One patch for the cosmetics One patch for the CHAR_DEBUG/av_dlog One patch for the addition of av_log One patch for the reflow of init_decoder() One patch for the roll-up functionality One patchset to rule them all. Thank you. [...] -- Clément B. pgpKBNAOx7F22.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Adding Closed caption Support
On Tue, Jan 13, 2015 at 08:12:10AM +0100, Clément Bœsch wrote: > On Tue, Jan 13, 2015 at 11:26:06AM +0530, Anshul Maheshwari wrote: > [...] > > > Also added roll-up functionality. > > > > > > patch is attached. > > > Thanks > > > Anshul > > > > > Attaching patch > > > From ca66e917f45bd47dd797930423d488fa9c781c4c Mon Sep 17 00:00:00 2001 > > From: Anshul Maheshwari > > Date: Mon, 12 Jan 2015 06:21:18 -0800 > > Subject: [PATCH] Addig Rollup functionality > > > > Signed-off-by: Anshul Maheshwari > > --- > > libavcodec/ccaption_dec.c | 222 > > +- > > 1 file changed, 140 insertions(+), 82 deletions(-) > > > > Please split your changes. > > One patch for the cosmetics > One patch for the CHAR_DEBUG/av_dlog > One patch for the addition of av_log > One patch for the reflow of init_decoder() > One patch for the roll-up functionality > One patchset to rule them all. > > Thank you. > hint: git add -p is your friend -- Clément B. pgpSjCSFasQZR.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
