Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: Handle non-square pixel aspect ratios
On Fri, 16 Jan 2015 22:17:56 +0100 Nicolas George wrote: > Le septidi 27 nivôse, an CCXXIII, Philip Langdale a écrit : > > Right. It is display aspect ratio, not sample aspect ratio. And then > > you have the 45/44 problem, unless that's somehow just affecting me. > > IIRC, the tests you ran were not accurate enough to know for sure. I > suggest the following test case: > > - start with a 832 × 448 input (testsrc=s=832x448 should do the > trick); > > - force darWidth / darHeight = 19 / 17 (patching the source directly > seems like the simplest way of doing it for this kind of tests); > > - encode to H.265 elementary stream; > > - check the output file with the ffmpeg summary AND ffprobe > -show_stream AND ffmpeg -vf showinfo -f null -. > > The numbers are selected with unambiguous prime factors. > > I do not have access to nvidia hardware, so I can not run the tests. Ok. I did this test and it produces correct results - SAR 133:221 which yields the correct final aspect ratio, but if I try and do a real world case, like my PAL DVD, it goes wrong - and Timo's patch goes wrong too, with this same weird 1.02 (45/44) scale factor. It's making my head hurt. So I feed in this input: Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 720x576 [SAR 64:45 DAR 16:9], 25 tbr, 25 tbn, 25 tbc With libx264, I get the same SAR and DAR out. With nvenc, I get: sample_aspect_ratio=16:11 display_aspect_ratio=20:11 which is everything off by ~1.02. That's with Timo's patch and with hard-coding the darWidth and darHeight to 1024x576. Same result. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Make CFR frame drop threshold user adjustable
Signed-off-by: Michael Niedermayer
---
ffmpeg.c |4 +++-
ffmpeg.h |1 +
ffmpeg_opt.c |3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 2501e2c..42ab379 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -963,7 +963,9 @@ static void do_video_out(AVFormatContext *s,
}
case VSYNC_CFR:
// FIXME set to 0.5 after we fix some dts/pts bugs like in avidec.c
-if (delta < -1.1)
+if (frame_drop_threshold && delta < frame_drop_threshold &&
ost->frame_number) {
+nb_frames = 0;
+} else if (delta < -1.1)
nb_frames = 0;
else if (delta > 1.1) {
nb_frames = lrintf(delta);
diff --git a/ffmpeg.h b/ffmpeg.h
index 0ad1e37..2969ff5 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -479,6 +479,7 @@ extern float dts_error_threshold;
extern int audio_volume;
extern int audio_sync_method;
extern int video_sync_method;
+extern float frame_drop_threshold;
extern int do_benchmark;
extern int do_benchmark_all;
extern int do_deinterlace;
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index a0c977b..e3f84dd 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -86,6 +86,7 @@ float dts_error_threshold = 3600*30;
int audio_volume = 256;
int audio_sync_method = 0;
int video_sync_method = VSYNC_AUTO;
+float frame_drop_threshold = 0;
int do_deinterlace= 0;
int do_benchmark = 0;
int do_benchmark_all = 0;
@@ -2870,6 +2871,8 @@ const OptionDef options[] = {
" \"dv\", \"dv50\", \"pal-vcd\", \"ntsc-svcd\", ...)", "type" },
{ "vsync", HAS_ARG | OPT_EXPERT,{
opt_vsync },
"video sync method", "" },
+{ "frame_drop_threshold", HAS_ARG | OPT_FLOAT | OPT_EXPERT, {
&frame_drop_threshold },
+"frame drop threshold", "" },
{ "async", HAS_ARG | OPT_INT | OPT_EXPERT, {
&audio_sync_method },
"audio sync method", "" },
{ "adrift_threshold", HAS_ARG | OPT_FLOAT | OPT_EXPERT, {
&audio_drift_threshold },
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] 10 Bit support for Decklink input device
On Sun, Jan 11, 2015 at 09:01:20PM +0530, Anshul wrote:
> On 01/11/2015 08:08 PM, Georg Lippitsch wrote:
> > ---
> > libavdevice/decklink_common_c.h | 1 +
> > libavdevice/decklink_dec.cpp| 18 ++
> > libavdevice/decklink_dec_c.c| 1 +
> > 3 files changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavdevice/decklink_common_c.h
> > b/libavdevice/decklink_common_c.h
> > index 861a51a..fb2b788 100644
> > --- a/libavdevice/decklink_common_c.h
> > +++ b/libavdevice/decklink_common_c.h
> > @@ -28,5 +28,6 @@ struct decklink_cctx {
> > int list_devices;
> > int list_formats;
> > double preroll;
> > +int v210;
> > };
> >
> > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > index 77a0fe5..747f47e 100644
> > --- a/libavdevice/decklink_dec.cpp
> > +++ b/libavdevice/decklink_dec.cpp
> > @@ -233,6 +233,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
> >ctx->video_st->time_base.den);
> >
> > if (videoFrame->GetFlags() & bmdFrameHasNoInputSource) {
> > +if (videoFrame->GetPixelFormat() == bmdFormat8BitYUV) {
> > unsigned bars[8] = {
> > 0xEA80EA80, 0xD292D210, 0xA910A9A5, 0x90229035,
> > 0x6ADD6ACA, 0x51EF515A, 0x286D28EF, 0x10801080 };
> > @@ -244,6 +245,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
> > for (int x = 0; x < width; x += 2)
> > *p++ = bars[(x * 8) / width];
> > }
> > +}
> >
> > if (!no_video) {
> > av_log(avctx, AV_LOG_WARNING, "Frame received (#%lu) - No
> > input signal detected "
> > @@ -466,15 +468,21 @@ av_cold int ff_decklink_read_header(AVFormatContext
> > *avctx)
> > goto error;
> > }
> > st->codec->codec_type = AVMEDIA_TYPE_VIDEO;
> > -st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> > st->codec->width = ctx->bmd_width;
> > st->codec->height = ctx->bmd_height;
> >
> > -st->codec->pix_fmt = AV_PIX_FMT_UYVY422;
> > st->codec->time_base.den = ctx->bmd_tb_den;
> > st->codec->time_base.num = ctx->bmd_tb_num;
> > st->codec->bit_rate= avpicture_get_size(st->codec->pix_fmt,
> > ctx->bmd_width, ctx->bmd_height) * 1/av_q2d(st->codec->time_base) * 8;
> > -st->codec->codec_tag = MKTAG('U', 'Y', 'V', 'Y');
> > +
> > +if (cctx->v210) {
> > +st->codec->codec_id= AV_CODEC_ID_V210;
> > +st->codec->codec_tag = MKTAG('V', '2', '1', '0');
> > +} else {
> > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> > +st->codec->pix_fmt = AV_PIX_FMT_UYVY422;
> > +st->codec->codec_tag = MKTAG('U', 'Y', 'V', 'Y');
> > +}
> >
> > avpriv_set_pts_info(st, 64, 1, 100); /* 64 bits pts in us */
> >
> > @@ -487,7 +495,9 @@ av_cold int ff_decklink_read_header(AVFormatContext
> > *avctx)
> > goto error;
> > }
> >
> > -result = ctx->dli->EnableVideoInput(ctx->bmd_mode, bmdFormat8BitYUV,
> > bmdVideoInputFlagDefault);
> > +result = ctx->dli->EnableVideoInput(ctx->bmd_mode,
> > +cctx->v210 ? bmdFormat10BitYUV :
> > bmdFormat8BitYUV,
> > +bmdVideoInputFlagDefault);
> >
> Why not save bmdFormat10BitYUV in cctx instead of 1 or 0 in cctx->v210 flag?
maybe AV_OPT_TYPE_PIXEL_FMT in the AVOption array could be used
if the intent is to make it more generic, i would avoid using
the libs internal types though
> > if (result != S_OK) {
> > av_log(avctx, AV_LOG_ERROR, "Cannot enable video input\n");
> > diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
> > index 2aea277..b1a65e6 100644
> > --- a/libavdevice/decklink_dec_c.c
> > +++ b/libavdevice/decklink_dec_c.c
> > @@ -31,6 +31,7 @@
> > static const AVOption options[] = {
> > { "list_devices", "list available devices" , OFFSET(list_devices),
> > AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
> > { "list_formats", "list supported formats" , OFFSET(list_formats),
> > AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
> > +{ "bm_v210", "v210 10 bit per channel" , OFFSET(v210),
> > AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
> > { NULL },
> > };
> >
> can you please add in commit message how should I test it. it would be
> easier for me.
> I do have a bmdcard on my linux pc.
> It would give me a link to add closed caption, because that comes only
> in 10bit yuv bmdcapture
> card.
>
> -Anshul
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for
Re: [FFmpeg-devel] Adding Closed caption in nut muxer
On Tue, Jan 13, 2015 at 02:20:42PM +0100, Michael Niedermayer wrote: > On Tue, Jan 13, 2015 at 12:00:36PM +0100, Nicolas George wrote: > > Le quartidi 24 nivôse, an CCXXIII, Anshul a écrit : > > > Please find attachment. > > > Using this people can also mux cc608 stream in nut muxer > > > > IIRC, you need to submit a patch to libnut before, because it holds the > > official list of codes. > > libnut is an implementation of teh nut spec > the nut spec is at > svn://svn.mplayerhq.hu/nut > > see docs/nut4cc.txt > > also: > https://lists.mplayerhq.hu/mailman/listinfo/nut-devel > > to add a new fourcc code to nut, send a patch that changes > docs/nut4cc.txt to nut-devel ping -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Reduce noisiness of frame clipping in rate convertion
Signed-off-by: Michael Niedermayer
---
ffmpeg.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 633dadd..01458d2 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -944,7 +944,10 @@ static void do_video_out(AVFormatContext *s,
format_video_sync != VSYNC_PASSTHROUGH &&
format_video_sync != VSYNC_DROP) {
double cor = FFMIN(-delta0, duration);
-av_log(NULL, AV_LOG_WARNING, "Past duration %f too large\n", -delta0);
+if (delta0 < -0.6) {
+av_log(NULL, AV_LOG_WARNING, "Past duration %f too large\n",
-delta0);
+} else
+av_log(NULL, AV_LOG_DEBUG, "Cliping frame in rate convertion by
%f\n", -delta0);
sync_ipts += cor;
duration -= cor;
delta0 += cor;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Favor filter graph based duration over ost->frame_rate in fps code
The fate change adds a last frame with a subtitle not displayed in the previous Signed-off-by: Michael Niedermayer --- ffmpeg.c | 11 --- tests/ref/fate/sub2video |1 + 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/ffmpeg.c b/ffmpeg.c index 2501e2c..633dadd 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -900,15 +900,12 @@ static void do_video_out(AVFormatContext *s, if (ost->source_index >= 0) ist = input_streams[ost->source_index]; -if(ist && ist->st->start_time != AV_NOPTS_VALUE && ist->st->first_dts != AV_NOPTS_VALUE && ost->frame_rate.num) -duration = 1/(av_q2d(ost->frame_rate) * av_q2d(enc->time_base)); - -// We take the conservative approuch here and take the minimum even though -// this should be correct on its own but a value too small is harmless, one -// too big can lead to errors if (filter->inputs[0]->frame_rate.num > 0 && filter->inputs[0]->frame_rate.den > 0) -duration = FFMIN(duration, 1/(av_q2d(filter->inputs[0]->frame_rate) * av_q2d(enc->time_base))); +duration = 1/(av_q2d(filter->inputs[0]->frame_rate) * av_q2d(enc->time_base)); + +if(ist && ist->st->start_time != AV_NOPTS_VALUE && ist->st->first_dts != AV_NOPTS_VALUE && ost->frame_rate.num) +duration = FFMIN(duration, 1/(av_q2d(ost->frame_rate) * av_q2d(enc->time_base))); if (!ost->filters_script && !ost->filters && diff --git a/tests/ref/fate/sub2video b/tests/ref/fate/sub2video index 1c6cdaf..5c2c46a 100644 --- a/tests/ref/fate/sub2video +++ b/tests/ref/fate/sub2video @@ -52,6 +52,7 @@ 0, 47, 47,1, 518400, 0xde69683f 0, 48, 48,1, 518400, 0x7df08fba 0, 49, 49,1, 518400, 0xbab197ea +0, 50, 50,1, 518400, 0x902285d9 1, 15355, 15355, 4733, 2094, 0x3c171425, F=0x0 1, 48797, 48797, 2560, 2480, 0x7c0edf21, F=0x0 1, 51433, 51433, 2366, 3059, 0xc95b8a05, F=0x0 -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/nvenc: Handle non-square pixel aspect ratios
---
libavcodec/nvenc.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 90856be..3fcfc9b 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -471,6 +471,7 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
int i, num_mbs;
int isLL = 0;
int res = 0;
+int dw, dh;
NvencContext *ctx = avctx->priv_data;
NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
@@ -564,8 +565,20 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
ctx->init_encode_params.encodeGUID = NV_ENC_CODEC_H264_GUID;
ctx->init_encode_params.encodeHeight = avctx->height;
ctx->init_encode_params.encodeWidth = avctx->width;
-ctx->init_encode_params.darHeight = avctx->height;
-ctx->init_encode_params.darWidth = avctx->width;
+
+if (avctx->sample_aspect_ratio.num && avctx->sample_aspect_ratio.den &&
+(avctx->sample_aspect_ratio.num != 1 || avctx->sample_aspect_ratio.num
!= 1)) {
+av_reduce(&dw, &dh,
+ avctx->width * avctx->sample_aspect_ratio.num,
+ avctx->height * avctx->sample_aspect_ratio.den,
+ 1024 * 1024);
+ctx->init_encode_params.darHeight = dh;
+ctx->init_encode_params.darWidth = dw;
+} else {
+ctx->init_encode_params.darHeight = avctx->height;
+ctx->init_encode_params.darWidth = avctx->width;
+}
+
ctx->init_encode_params.frameRateNum = avctx->time_base.den;
ctx->init_encode_params.frameRateDen = avctx->time_base.num *
avctx->ticks_per_frame;
--
2.2.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: Handle non-square pixel aspect ratios
Le septidi 27 nivôse, an CCXXIII, Philip Langdale a écrit : > Right. It is display aspect ratio, not sample aspect ratio. And then > you have the 45/44 problem, unless that's somehow just affecting me. IIRC, the tests you ran were not accurate enough to know for sure. I suggest the following test case: - start with a 832 × 448 input (testsrc=s=832x448 should do the trick); - force darWidth / darHeight = 19 / 17 (patching the source directly seems like the simplest way of doing it for this kind of tests); - encode to H.265 elementary stream; - check the output file with the ffmpeg summary AND ffprobe -show_stream AND ffmpeg -vf showinfo -f null -. The numbers are selected with unambiguous prime factors. I do not have access to nvidia hardware, so I can not run the tests. 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] Force text files to be downloaded in UNIX line ending (LF)
I verified that GNU Make 4.1 in MSYS2 environment builds FFmpeg without any issue regardless of the line ending. This is good and I recommend MSYS2 usage for building FFmpeg for WinRT in the wiki below: https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT However, the official documentation and the wiki still suggest that MinGW/MSYS as the default environment to build FFmpeg on Windows. For example MSYS web link points directly to the MinGW/MSYS web page. If MSYS2 is in fact the recommended shell to build FFmpeg in Windows, is there any upcoming effort to update these docs? Best Regards, Timotius Margo -Original Message- From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Matt Oliver Sent: Saturday, January 10, 2015 2:28 AM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] Force text files to be downloaded in UNIX line ending (LF) On 10 January 2015 at 21:18, Derek Buitenhuis wrote: > On 1/10/2015 8:40 AM, Timotius Margo wrote: > > This causes a problem with autoconf and prevents user from building > > FFmpeg successfully without applying a workaround. > > I forgot to mention this is fixed in newer make.exe's, and I think > it's included in MSYS2. > It is included in MSYS2 as current versions dont seem to have this problem at all. Which is just another reason why *IF* anything is going to be mentioned/recommended then it should be MSYS2 and not MSYS/MinGW setups. Although this may be a good example of why it could be useful to make it clear somewhere that MSYS2 is the recommended setup to help avoid these issues that way. ___ 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 2/3] avcodec/nvenc: Handle non-square pixel aspect ratios
On 2015-01-15 23:48, Nicolas George wrote: Le septidi 27 nivôse, an CCXXIII, Timo Rothenpieler a écrit : +av_reduce(&dw, &dh, avctx->sample_aspect_ratio.num, avctx->sample_aspect_ratio.den, 4096); +ctx->init_encode_params.darHeight = dw; +ctx->init_encode_params.darWidth = dh; Has this been actually tested? "dar" in the API does not seem to be the same thing as sample_aspect_ratio in FFmpeg's API. Right. It is display aspect ratio, not sample aspect ratio. And then you have the 45/44 problem, unless that's somehow just affecting me. --phil ___ 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 Wed, Jan 14, 2015 at 06:26:06PM +0100, Michael Niedermayer wrote: > ive no idea how portable it is but one way to avoid most of the > mess would be to use attribute weak / lazy linking > that way as long as lib functions arent called nothing should try to > load the lib and so it should work with unresolved references > > something like dlopen would need to be used to detect if the > lib is available or not before registering the lib wraper > > if that would work it should be alot cleaner / require significantly > less code per lib, but its quite possible that this simply wouldnt > work on some platforms, ive no idea, ive never tried it It's also possible to do similar things without linker tricks. E.g. define all functions as macros to add a ff_dl_wrap prefix, then you can implement those wrappers in a different file and from there do all the dlopen handling (making them function pointers would probably be an option, too). There are many options how to do things in detail from there on, though most likely it would make sense to try to dlopen/dlsym all libraries when registering the codecs (and not register those where dlopen or one dlsym fails). Adding a header that contains those defines should then be the only change besides the dlopen logic itself that should be necessary. There might even be some way to auto-generate some of the code. If you rely on Bsymbolic linking (possible even without it), the macros to rename the functions might not even be necessary. The lazy linking even where supported has the risk that dlopen or whatever you used worked but the symbol then isn't found in the end, and then you get crashes... It's a least-impact approach, but it seems risky. ___ 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 1/16/2015 12:47 AM, Stephen Hutchinson wrote: > There have been times I've run into issues > because a shared library FFmpeg was linked against somehow > got removed or was updated and broke compatibility. [...] > Dynamic loading allows the main binary to still function > correctly if this occurs, with the issue only arising if the user > attempts to use the missing library, in which case the > methodology of doing dynamic loading allows for a graceful > exit rather than the program crashing. This is definitely wrong. An ABI break would still have the *exact* same issues as before, when the wrong library is loaded. In fact, it's worse, since it potentially ignores the soname. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] aversion to .cpp files?
On 1/16/2015 9:02 AM, Clément Bœsch wrote: > I believe there is a large perference for C. Not only that, but our configure is downright broken for C++ files, so to speak. We hardcode libstdc++, which is de facto wrong. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] aversion to .cpp files?
On Thu, Jan 15, 2015 at 07:45:57AM -0700, Roger Pack wrote: > Hello. I've noticed there are a few .cpp files in the codebase, but > not many (most seem to be tied to windows). > > I have the choice, with the dshow stuff, to write in its "native" cpp > style (much easier/clearer IMO) or to convert it to straight "c > wrapper" style stuff. Is there a large preference for either? CPP > might be more compatible [possibly] though I have not confirmed that, > as well. > Thank you. If no response I'll stick with CPP. > thanks! I believe there is a large perference for C. > -roger- Regards, -- Clément B. pgpOYUERFU4gO.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
