Re: [FFmpeg-devel] [PATCH 16/17] avdevice/dshow: Initialize 2 pointers
On Sun, Jun 2, 2024 at 12:58 PM Michael Niedermayer wrote: > > On Mon, May 27, 2024 at 01:52:28AM +0200, Michael Niedermayer wrote: > > Coverity claims these are used uninitilaized in CID1598561 Uninitialized > > pointer write and CID1598565 Uninitialized pointer write > > > > Sponsored-by: Sovereign Tech Fund > > Signed-off-by: Michael Niedermayer > > --- > > libavdevice/dshow.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > will apply They seemed to LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] Fix missing PCM sample size option when it is used as the lone option for DirectShow audio capture
I have looked at these two patches and they look good to me, if anybody could commit them for me, that would be great. On Wed, Nov 3, 2021 at 8:10 PM Brad Isbell wrote: > > From 25e34ef9f995afffe67e519bb6f03a750aa09ae2 Mon Sep 17 00:00:00 2001 > From: Brad Isbell > Date: Wed, 3 Nov 2021 20:38:59 -0500 > Subject: [PATCH 2/2] Fix missing PCM sample size option when it is used as > the > lone option for DirectShow audio capture > > Signed-off-by: Brad Isbell > --- > libavdevice/dshow.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c > index 5c1e494..e313c9a 100644 > --- a/libavdevice/dshow.c > +++ b/libavdevice/dshow.c > @@ -569,7 +569,7 @@ dshow_cycle_pins(AVFormatContext *avctx, enum > dshowDeviceType devtype, > (ctx->requested_width && > ctx->requested_height) || > ctx->pixel_format != > AV_PIX_FMT_NONE || > ctx->video_codec_id != > AV_CODEC_ID_RAWVIDEO)) > - || (devtype == AudioDevice && (ctx->channels || > ctx->sample_rate)); > + || (devtype == AudioDevice && (ctx->channels || > ctx->sample_rate || ctx->sample_size)); > int format_set = 0; > int should_show_properties = (devtype == VideoDevice) ? > ctx->show_video_device_dialog : ctx->show_audio_device_dialog; > > -- > 2.32.0.windows.1 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Possible memory leaks in dshow capture
Thanks for cleaning that up! On Thu, Jan 3, 2019 at 9:32 AM James Almer wrote: > > On 1/3/2019 1:12 PM, Oliver Collyer wrote: > > Version created using git format-patch. > > Applied, thanks. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Initialize DirectShow source filters with IFileSourceFilter::Load
On Fri, Sep 21, 2018 at 3:19 PM Maxim Ershtein wrote: > > Hello, > > ffmpeg allows capturing a/v from custom DirectShow source filters, and > provides some methods to pass parameters to these filters, but these > methods seem insufficient. > > So ffmpeg offers to launch a filter configuration dialog via > -show_video_device_dialog > , however, it doesn't work on some filters, but most importantly, it is not > a programmatic way; you need to have a user configuring the filter. > > I wrote an issue report yesterday to ffmpeg-users: > http://www.ffmpeg-archive.org/Cannot-receive-audio-video-from-Unreal-WebRTC-DirectShow-Source-filter-td4685353.html > > The principal problem is with network capture filters that must be > initialized with URL or some network address, in order for them to get the > stream and construct a media type on the output pins. > They don't have any output media type once instantiated - they must be > initialized in order to have a media type. Depending on network address > where they pull a stream from, this media type can be very different. > > So a feature suggestion is to use a common COM interface used in DirectShow > for this purpose: > IFileSourceFilter. Notice how GraphEdit pops up an open file dialog > prompting you to load a configuration file, when you try to add source > filter that supports this interface. > > So, ffmpeg can have a command-line parameter, like > *-IFileSourceFilter_Init_String.* > If this parameter is passed, AND source filter supports IFileSourceFilter, > then ffmpeg calls IFileSourceFilter::Load with that parameter. > > Any other idea of how to programmatically pass *custom* parameters to > source filters, > is welcomed. Yeah I attempted to research it once and didn't get very far https://stackoverflow.com/questions/14050074/how-to-change-directshow-filter-properties-c/27931102#27931102 If IFileSourceFilter is common then that's a legit option... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] --extra-ldexeflags don't take precedence
As a note, configuring with ... --extra-ldexeflags=-Wl,--image-base,0x1000 ... results in a link time command of /Users/rdp/dev/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/bin/x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x1000 -Wl,--pic-executable,-e,mainCRTStartup -Wl,--image-base,0x14000 -I/Users/rdp/dev/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/include -L/Users/rdp/dev/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib/ -L/Users/rdp/dev/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib -o /var/folders/52/02ywtc9j2n9145q29g58g5s4gn/T//ffconf.J0wHA7pr/test.exe /var/folders/52/02ywtc9j2n9145q29g58g5s4gn/T//ffconf.J0wHA7pr/test.o -lrtmfp -lstdc++ -lWs2_32 -liphlpapi -lssl -lcrypto -lstdc++ -lWs2_32 -liphlpapi -lssl -lcrypto -lstdc++ -lWs2_32 -liphlpapi -lssl -lcrypto -lssl -lcrypto -lz -lws2_32 -lgdi32 -lcrypt32 -lpthread -lm -lmingwex notice how the "0x1000" part came *before* the default, which is "-Wl,--image-base,0x14000" so there is essentially no way to override this setting from the configure line. Perhaps this is expected, surprised me at least... Cheers! -Roger ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixing rare dshow input crash
Original bigger patch is enough for now. Please merge, thanks! On Wed, Jan 29, 2020 at 1:40 AM Paul B Mahol wrote: > > Please incorporate this change in previous bigger patch. It is ready for > merge. > > On 1/29/20, Roger Pack wrote: > > Good catch. > > Or maybe this? > > > > diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c > > index d7f5bd7..96e4374 100644 > > --- a/libavdevice/dshow.c > > +++ b/libavdevice/dshow.c > > @@ -453,6 +453,7 @@ next: > > if (type->pbFormat) > > CoTaskMemFree(type->pbFormat); > > CoTaskMemFree(type); > > +type = NULL; > > } > > end: > > IAMStreamConfig_Release(config); > > > > On Thu, Sep 5, 2019 at 2:56 PM Alexey Potakhov wrote: > >> > >> re-sending without tabs. > >> > >> On Wed, Sep 4, 2019 at 6:22 PM Carl Eugen Hoyos > >> wrote: > >> > > >> > Am Do., 5. Sept. 2019 um 00:08 Uhr schrieb Alexey Potakhov > >> > : > >> > > >> > > In some rare cases when IAMStreamConfig_GetStreamCaps returns > >> > > an error avformat_open_input() crashes with access violation. > >> > > >> > Tabs are rejected by our repository, please remove them and resend. > >> > > >> > Carl Eugen > >> > ___ > >> > ffmpeg-devel mailing list > >> > ffmpeg-devel@ffmpeg.org > >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > >> > To unsubscribe, visit link above, or email > >> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Fixing rare dshow input crash
On Wed, Feb 26, 2020 at 4:36 AM Carl Eugen Hoyos wrote: > > Am Mi., 26. Feb. 2020 um 06:57 Uhr schrieb Roger Pack : > > > > Original bigger patch is enough for now. Please merge, thanks! > > What happened to your git account? I never made one. Do we still send in private keys for it? If so to whom? Thanks. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] How to satisfy two codecs with one decoder?
I want to add to the closed caption libavcodec/ccaption_dec.c decoder
to be able to handle both 608 "over CEA 708" (which it already does)
and also "raw EIA 608 byte pairs" which it doesn't.
My idea was to introduce a new codec id for the raw 608 pairs.
AV_CODEC_ID_EIA_RAW_608 or the like.
The decoding shares a lot of functionality.
Currently the decoder code is set up like this:
AVCodec ff_ccaption_decoder = {
.name = "cc_dec",
.long_name = NULL_IF_CONFIG_SMALL("Closed Caption (EIA-608 / CEA-708)"),
.type = AVMEDIA_TYPE_SUBTITLE,
.id = AV_CODEC_ID_EIA_608,
...
I was hoping to "add" another codec like AV_CODEC_ID_EIA_RAW_608 and
having this decoder be able to decode both types.
I was anticipating being able to define some kind of "query" method so
it would check if the requested codec id was "either
AV_CODEC_ID_EIA_608 or AV_CODEC_ID_EIA_RAW_608" and accept decoding
either codec.
Is there a way for a codec to decode two id's like this?
If not any recommendations on how to best handle this?
Thanks.
-Roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] closed caption decoder: add new parameter to allow output to avoid repeated lines
I didn't actually *need* this but thought the functionality was very nice to have, so here's my contribution. It allows for forcing "rollup" style closed captions to output one line at a time (basically, when there is a carriage return, it outputs a line), so there is never any duplication in the output, for instance if it's converted to .srt or .vtt files. Without this you have output like this: 00:01.536 --> 00:03.605 AND AS A SECONDARY QUESTION, I 00:03.605 --> 00:05.707 AND AS A SECONDARY QUESTION, I WOULD ASK YOU HOW OUR VETERANS 00:05.706 --> 00:09.343 WOULD ASK YOU HOW OUR VETERANS AND ACTIVE DUTY MILITARY HAVE 00:09.344 --> 00:10.412 AND ACTIVE DUTY MILITARY HAVE FARED UNDER THIS COMMANDER IN With it set to "1" you get output like this: 00:02.014 --> 00:03.049 SOLDIERS HOME IN HOLYOKE, 00:03.048 --> 00:04.116 MASSACHUSETTS, HAVE LOST 73. 00:04.116 --> 00:04.850 ANOTHER FACILITY IN NEW ORLEANS, 00:04.850 --> 00:06.184 53. 00:06.184 --> 00:07.753 VETERANS ARE IN REAL PERIL 00:07.753 --> 00:14.193 BECAUSE OF A LACK OF PREPARATION 00:14.193 --> 00:15.727 AND THEN THE SAME DYSFUNCTION ... Thanks. 0002-closed-caption-decoder-add-new-parameter-to-allow-ou.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
I needed this in order to be able to parse raw analog TV closed caption byte pairs (analog line 21 CC's). 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] How to satisfy two codecs with one decoder?
On Fri, Apr 17, 2020 at 4:53 PM James Almer wrote:
>
> On 4/17/2020 7:40 PM, Roger Pack wrote:
> > I want to add to the closed caption libavcodec/ccaption_dec.c decoder
> > to be able to handle both 608 "over CEA 708" (which it already does)
> > and also "raw EIA 608 byte pairs" which it doesn't.
> >
> > My idea was to introduce a new codec id for the raw 608 pairs.
> > AV_CODEC_ID_EIA_RAW_608 or the like.
> >
> > The decoding shares a lot of functionality.
> >
> > Currently the decoder code is set up like this:
> >
> > AVCodec ff_ccaption_decoder = {
> > .name = "cc_dec",
> > .long_name = NULL_IF_CONFIG_SMALL("Closed Caption (EIA-608 / CEA-708)"),
> > .type = AVMEDIA_TYPE_SUBTITLE,
> > .id = AV_CODEC_ID_EIA_608,
> > ...
> >
> > I was hoping to "add" another codec like AV_CODEC_ID_EIA_RAW_608 and
> > having this decoder be able to decode both types.
> >
> > I was anticipating being able to define some kind of "query" method so
> > it would check if the requested codec id was "either
> > AV_CODEC_ID_EIA_608 or AV_CODEC_ID_EIA_RAW_608" and accept decoding
> > either codec.
> >
> > Is there a way for a codec to decode two id's like this?
> > If not any recommendations on how to best handle this?
>
> Usually, you set up two decoders that both reference the same functions
> (or most of them). In the case of shared function, they would then
> execute a different codepath depending on codec_id as required.
>
> See mpeg12dec.c and how both the mpeg1 and mpeg2 AVCodec entries are
> essentially the same for an example. Or the nvenc encoders.
Thanks that did it, those are good examples. One thing I did notice
is if two decoders use the same ".priv_class" then it causes an
infinite loop trying to find the next decoder to search for
parameters. But one past that, all is well...
Thanks!
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] directshow: add ability to read closed caption raw byte pairs from VBI pin
Here's the final piece (to actually use the new codec), where we allow
to read raw CC 608 byte pairs from
analog directshow TV capture devices ("read" in a loose sense of the
term, it requires an intermediate dshow filter to extract the CC raw
bytes from the VBI incoming stream, but anyway it works).
Many thanks to grabien for sponsoring this effort, and to the
maintainers of the closed caption decoder and
everyone else which made it possible.
From 77c622f308d112ec1ba2171ed6e96b8c0a2ea041 Mon Sep 17 00:00:00 2001
From: rogerdpack
Date: Tue, 28 Apr 2020 05:26:59 +
Subject: [PATCH 3/3] directshow: add ability to read closed caption raw byte
pairs from VBI pin
Signed-off-by: rogerdpack
---
doc/indevs.texi | 15 ++-
libavdevice/dshow.c | 89 ++---
libavdevice/dshow_capture.h | 16 ---
libavdevice/dshow_pin.c | 12 +++--
4 files changed, 95 insertions(+), 37 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6f5afaf344..21d35d118a 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -452,8 +452,12 @@ The input name should be in the format:
@var{TYPE}=@var{NAME}[:@var{TYPE}=@var{NAME}]
@end example
-where @var{TYPE} can be either @var{audio} or @var{video},
-and @var{NAME} is the device's name or alternative name..
+where @var{TYPE} can be either @var{audio}, @var{video}, or @var{closed_caption}
+and @var{NAME} is the device's name or alternative name.
+
+@var{closed_caption} devices must advertise format VBI and have an intermediate
+directshow filter available to convert from VBI to raw EIA 608 closed caption
+format byte pairs.
@subsection Options
@@ -615,6 +619,13 @@ Open video device @var{Camera} and audio device @var{Microphone}:
$ ffmpeg -f dshow -i video="Camera":audio="Microphone"
@end example
+@item
+Open video device @var{Camera}, closed caption device @var{Camera},
+and audio device @var{Microphone}:
+@example
+$ ffmpeg -f dshow -i video="Camera":audio="Microphone":closed_caption="Camera"
+@end example
+
@item
Print the list of supported options in selected device and exit:
@example
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index d7f5bd7069..18f8085db4 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -90,24 +90,34 @@ dshow_read_close(AVFormatContext *s)
libAVPin_Release(ctx->capture_pin[VideoDevice]);
if (ctx->capture_pin[AudioDevice])
libAVPin_Release(ctx->capture_pin[AudioDevice]);
+if (ctx->capture_pin[ClosedCaptionDevice])
+libAVPin_Release(ctx->capture_pin[ClosedCaptionDevice]);
if (ctx->capture_filter[VideoDevice])
libAVFilter_Release(ctx->capture_filter[VideoDevice]);
if (ctx->capture_filter[AudioDevice])
libAVFilter_Release(ctx->capture_filter[AudioDevice]);
+if (ctx->capture_filter[ClosedCaptionDevice])
+libAVFilter_Release(ctx->capture_filter[ClosedCaptionDevice]);
if (ctx->device_pin[VideoDevice])
IPin_Release(ctx->device_pin[VideoDevice]);
if (ctx->device_pin[AudioDevice])
IPin_Release(ctx->device_pin[AudioDevice]);
+if (ctx->device_pin[ClosedCaptionDevice])
+IPin_Release(ctx->device_pin[ClosedCaptionDevice]);
if (ctx->device_filter[VideoDevice])
IBaseFilter_Release(ctx->device_filter[VideoDevice]);
if (ctx->device_filter[AudioDevice])
IBaseFilter_Release(ctx->device_filter[AudioDevice]);
+if (ctx->device_filter[ClosedCaptionDevice])
+IBaseFilter_Release(ctx->device_filter[ClosedCaptionDevice]);
av_freep(&ctx->device_name[0]);
av_freep(&ctx->device_name[1]);
+av_freep(&ctx->device_name[2]);
av_freep(&ctx->device_unique_name[0]);
av_freep(&ctx->device_unique_name[1]);
+av_freep(&ctx->device_unique_name[2]);
if(ctx->mutex)
CloseHandle(ctx->mutex);
@@ -219,8 +229,8 @@ dshow_cycle_devices(AVFormatContext *avctx, ICreateDevEnum *devenum,
const GUID *device_guid[2] = { &CLSID_VideoInputDeviceCategory,
&CLSID_AudioInputDeviceCategory };
-const char *devtypename = (devtype == VideoDevice) ? "video" : "audio only";
-const char *sourcetypename = (sourcetype == VideoSourceDevice) ? "video" : "audio";
+const char *devtypename = (devtype == VideoDevice) ? "video" : (devtype == AudioDevice) ? "audio" : "VBI";
+const char *sourcetypename = (sourcetype == VideoSourceDevice) ? "video" : "audio only";
r = ICreateDevEnum_CreateClassEnumerator(devenum, device_guid[sourcetype],
(IEnumMoniker **) &classenum, 0);
@@ -569,9 +579,9 @@ dshow_cycle_pins(AVFormatContext *avctx, enum dshowDeviceType devtype,
IPin *pin;
int r;
-const GUID *mediatype[2] = { &MEDIATYPE_Video, &MEDIATYPE_Audio };
-const char *devtypename = (devtype == VideoDevice) ? "video" : "audio only";
-const char *sourcetypename = (sourcetype == VideoSourceDevice) ? "video" : "audio";
+
Re: [FFmpeg-devel] [PATCH 2/3] closed caption decoder: add new parameter to allow output to avoid repeated lines
On Tue, Apr 28, 2020 at 1:46 AM Hendrik Leppkes wrote: > > On Tue, Apr 28, 2020 at 8:19 AM Roger Pack wrote: > > > > I didn't actually *need* this but thought the functionality was very > > nice to have, so here's my contribution. > > > > It allows for forcing "rollup" style closed captions to output one > > line at a time (basically, when there is a carriage return, it outputs > > a line), so there is never any duplication in the output, for instance > > if it's converted to .srt or .vtt files. Without this you have output > > like this: > > > > > > 00:01.536 --> 00:03.605 > > AND AS A SECONDARY QUESTION, I > > > > 00:03.605 --> 00:05.707 > > AND AS A SECONDARY QUESTION, I > > WOULD ASK YOU HOW OUR VETERANS > > > > 00:05.706 --> 00:09.343 > > WOULD ASK YOU HOW OUR VETERANS > > AND ACTIVE DUTY MILITARY HAVE > > > > 00:09.344 --> 00:10.412 > > AND ACTIVE DUTY MILITARY HAVE > > FARED UNDER THIS COMMANDER IN > > > > With it set to "1" you get output like this: > > > > > > 00:02.014 --> 00:03.049 > > SOLDIERS HOME IN HOLYOKE, > > > > 00:03.048 --> 00:04.116 > > MASSACHUSETTS, HAVE LOST 73. > > > > 00:04.116 --> 00:04.850 > > ANOTHER FACILITY IN NEW ORLEANS, > > > > 00:04.850 --> 00:06.184 > > 53. > > > > 00:06.184 --> 00:07.753 > > VETERANS ARE IN REAL PERIL > > > > 00:07.753 --> 00:14.193 > > BECAUSE OF A LACK OF PREPARATION > > > > 00:14.193 --> 00:15.727 > > AND THEN THE SAME DYSFUNCTION > > > > I would've figured that even when you split it into individual lines, > that each line would show for the same amount as it did before, ie. > with overlap in the SRT. Otherwise, some lines like the "ANOTHER > FACILITY IN NEW ORLEANS," one are shown for not even a second, which > seems pretty bad. The chief goal of the new setting is to make it easier for automated processes to parse the output (realtime or otherwise). Like "read from analog tuner and tail the .vtt file and see what the subtitles are" without having to worry about duplication of lines. So it not displaying for long isn't a problem in this case. This seems like a useful functionality for me. The goal here is to just show the latest line in the .srt output, no previous lines. I think that's useful, though not for display purposes, in which case they can just use the default anyway? Thanks. -roger- > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
> > c9153590e5f167e41910d867639eb887164e28d2
> > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001
> > From: rogerdpack
> > Date: Tue, 28 Apr 2020 05:15:15 +
> > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec
> > type of 'raw 608 byte pairs'
>
> breaks fate
>
> TESTsub-cc-realtime
> --- ./tests/ref/fate/sub-cc-realtime2020-04-28 15:43:10.506887112 +0200
> +++ tests/data/fate/sub-cc-realtime 2020-04-28 19:31:37.164407976 +0200
OK I believe to have fixed that, see the latest attached. Plus a few
more aesthetic cleanups to boot.
Thanks!
From 5d7c12a3f703e794e1092087355bc9523d5f4d93 Mon Sep 17 00:00:00 2001
From: rogerdpack
Date: Tue, 28 Apr 2020 05:15:15 +
Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec
type of 'raw 608 byte pairs'
Signed-off-by: rogerdpack
---
configure | 1 +
libavcodec/Makefile | 2 +-
libavcodec/allcodecs.c| 1 +
libavcodec/ccaption_dec.c | 116 ++
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
libavcodec/version.h | 4 +-
7 files changed, 92 insertions(+), 40 deletions(-)
diff --git a/configure b/configure
index 080d93a129..8a0a6cce7c 100755
--- a/configure
+++ b/configure
@@ -2681,6 +2681,7 @@ bink_decoder_select="blockdsp hpeldsp"
binkaudio_dct_decoder_select="mdct rdft dct sinewin wma_freqs"
binkaudio_rdft_decoder_select="mdct rdft sinewin wma_freqs"
cavs_decoder_select="blockdsp golomb h264chroma idctdsp qpeldsp videodsp"
+ccaption_raw_608_decoder_select="ccaption_decoder"
clearvideo_decoder_select="idctdsp"
cllc_decoder_select="bswapdsp"
comfortnoise_encoder_select="lpc"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 28076c2c83..006eb40107 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -246,6 +246,7 @@ OBJS-$(CONFIG_C93_DECODER) += c93.o
OBJS-$(CONFIG_CAVS_DECODER)+= cavs.o cavsdec.o cavsdsp.o \
cavsdata.o
OBJS-$(CONFIG_CCAPTION_DECODER)+= ccaption_dec.o ass.o
+OBJS-$(CONFIG_CCAPTION_RAW_608_DECODER)+= ccaption_dec.o ass.o
OBJS-$(CONFIG_CDGRAPHICS_DECODER) += cdgraphics.o
OBJS-$(CONFIG_CDTOONS_DECODER) += cdtoons.o
OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o
@@ -463,7 +464,6 @@ OBJS-$(CONFIG_MP3ON4FLOAT_DECODER) += mpegaudiodec_float.o mpeg4audio.o
OBJS-$(CONFIG_MPC7_DECODER)+= mpc7.o mpc.o
OBJS-$(CONFIG_MPC8_DECODER)+= mpc8.o mpc.o
OBJS-$(CONFIG_MPEGVIDEO_DECODER) += mpeg12dec.o mpeg12.o mpeg12data.o
-OBJS-$(CONFIG_MPEG1VIDEO_DECODER) += mpeg12dec.o mpeg12.o mpeg12data.o
OBJS-$(CONFIG_MPEG1VIDEO_ENCODER) += mpeg12enc.o mpeg12.o
OBJS-$(CONFIG_MPEG1_CUVID_DECODER) += cuviddec.o
OBJS-$(CONFIG_MPEG1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 54d40ebdbc..b78f58cb4c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -645,6 +645,7 @@ extern AVCodec ff_ssa_decoder;
extern AVCodec ff_ass_encoder;
extern AVCodec ff_ass_decoder;
extern AVCodec ff_ccaption_decoder;
+extern AVCodec ff_ccaption_raw_608_decoder;
extern AVCodec ff_dvbsub_encoder;
extern AVCodec ff_dvbsub_decoder;
extern AVCodec ff_dvdsub_encoder;
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index bf3563a0bc..a2197cd673 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -341,43 +341,51 @@ static void write_char(CCaptionSubContext *ctx, struct Screen *screen, char ch)
}
/**
- * This function after validating parity bit, also remove it from data pair.
- * The first byte doesn't pass parity, we replace it with a solid blank
- * and process the pair.
- * If the second byte doesn't pass parity, it returns INVALIDDATA
- * user can ignore the whole pair and pass the other pair.
+ * This function accepts a byte pair [EIA 608 first byte, EIA 608 second byte]
+ * checks both for parity and strips parity on success.
+ * If the first byte doesn't pass parity, replace it with a solid blank
+ * and process the pair anyway.
+ * Returns failure for parity failure or "no data" (padding bytes).
+ */
+static int validate_eia_608_byte_pair(uint8_t *cc_data_pair) {
+if (!av_parity(cc_data_pair[1])) {
+return AVERROR_INVALIDDATA;
+}
+if (!av_parity(cc_data_pair[0])) {
+cc_data_pair[0]=0x7F; // solid blank
+}
+if ((cc_data_pair[0] & 0x7F) == 0 && (cc_data_pair[1] & 0x7F) == 0) {
+return AVERROR_INVALIDDATA; // padding bytes
+}
+/* remove parity bit */
+cc_data_pair[0] &= 0x7F;
+cc_data_pair[1] &= 0x7F;
+return 0;
+}
+
+/**
+ * This function accepts "cc_data_pair" = [708 header byte, EIA 608 first byte, EIA 608 second byte]
+ * This function after validating parity bits, also removes parity bits the
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya wrote: > > On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote: > > > > > c9153590e5f167e41910d867639eb887164e28d2 > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001 > > > > From: rogerdpack > > > > Date: Tue, 28 Apr 2020 05:15:15 + > > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new > > codec > > > > type of 'raw 608 byte pairs' > > > > How does this content exist? Are you defining your own file format with the > byte pairs? It's transmitted as "raw byte pairs" by analog TV broadcast in the US. https://en.wikipedia.org/wiki/EIA-608 has details. I believe it transmits one closed caption character (or control code) per frame (basically a single byte pair on "line 21") so it can do 30 closed caption chars/second. Anyway that's where it's originating from. Good question :) Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
On Fri, May 1, 2020 at 12:22 AM Kieran Kunhya wrote:
>
> On Fri, 1 May 2020 at 04:59, Roger Pack wrote:
>
> > On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya wrote:
> > >
> > > On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote:
> > >
> > > > > > c9153590e5f167e41910d867639eb887164e28d2
> > > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00
> > 2001
> > > > > > From: rogerdpack
> > > > > > Date: Tue, 28 Apr 2020 05:15:15 +
> > > > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a
> > new
> > > > codec
> > > > > > type of 'raw 608 byte pairs'
> > > >
> > >
> > > How does this content exist? Are you defining your own file format with
> > the
> > > byte pairs?
> >
> > It's transmitted as "raw byte pairs" by analog TV broadcast in the US.
> > https://en.wikipedia.org/wiki/EIA-608 has details.
> >
> > I believe it transmits one closed caption character (or control code)
> > per frame (basically a single byte pair on "line 21") so it can do 30
> > closed caption chars/second. Anyway that's where it's originating
> > from. Good question :)
> >
>
> Yes, but these byte pairs are usually in a container or exist in an
> analogue waveform.
It's from analogue waveform, it gets pulled out by the analog TV
decoder card into the byte pairs.
The container is basically "which frame" the line 21 data happened to
come in with. It comes in with two bytes/frame.
It comes in with a timestamp given by (I presume) the timestamp of the
frame it accompanies as a pin in directshow (in windows).
Directshow with the tuner card presents the line 21 data as "VBI
packets" (with a header specifying which portion of the VBI it comes
from, line 21 "odd" or line 21 "even"), and a timestamp.
There is another directshow filter that basically filters out the VBI
data and passes on just the "raw byte pairs" for a given CC stream.
See attached, but only concentrate on the "VBI Codec" filter box. It
presents two "CC" pins, the first of which we accept the byte pairs
from (with patch 3/3) [1]
So it's an analog standard, which directshow handles this way, and
it's converted to byte pairs.
> Have you defined your own format of "raw byte pairs"? That doesn't exist in
> the wild as far as I know.
The "format" is normal EIA 608
https://en.wikipedia.org/wiki/EIA-608
The "characters" section.
There was already a codec named "AV_CODEC_ID_EIA_608", but it was
really EIA 608 encapsulated within an EIA 708 stream, so I went with a
new name. The existing 608 decoder already decoded the "byte pairs"
internally I just needed to be able to access it without the
encapsulation for this particular input.
In the analog stream they "come in" on the line 21 data as EIA byte
pairs. No 708 encapsulation, hence me calling it "raw"
(AV_CODEC_ID_EIA_608_RAW_BYTE_PAIRS).
So it seems standard.
Cheers.
-roger-
[1] If you care about the nitty gritty, here's the media types that
the pins present:
VBI pin:
Media type: MEDIATYPE_VBI {F72A76E1-EB0A-11D0-ACE4-C0CC16BA}
Subtype: KSDATAFORMAT_SUBTYPE_RAW8 {CA20D9A0-3E3E-11D1-9BF9-00C04FBBDEBF}
Format type: {F72A76E0-EB0A-11D0-ACE4-C0CC16BA}
CC pin:
Media type: MEDIATYPE_AUXLine21Data {670AEA80-3A82-11D0-B79B-00AA003767A7}
Subtype: MEDIASUBTYPE_Line21_BytePair {6E8D4A22-310C-11D0-B79A-00AA003767A7}
Format type: FORMAT_None {0F6417D6-C318-11D0-A43F-00A0C9223196}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
Bump... On Wed, Apr 29, 2020 at 11:23 PM Roger Pack wrote: > > > > c9153590e5f167e41910d867639eb887164e28d2 > > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001 > > > From: rogerdpack > > > Date: Tue, 28 Apr 2020 05:15:15 + > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec > > > type of 'raw 608 byte pairs' > > > > breaks fate > > > > TESTsub-cc-realtime > > --- ./tests/ref/fate/sub-cc-realtime2020-04-28 15:43:10.506887112 +0200 > > +++ tests/data/fate/sub-cc-realtime 2020-04-28 19:31:37.164407976 +0200 > > OK I believe to have fixed that, see the latest attached. Plus a few > more aesthetic cleanups to boot. > > Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Fixing rare dshow input crash
Good catch. Or maybe this? diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c index d7f5bd7..96e4374 100644 --- a/libavdevice/dshow.c +++ b/libavdevice/dshow.c @@ -453,6 +453,7 @@ next: if (type->pbFormat) CoTaskMemFree(type->pbFormat); CoTaskMemFree(type); +type = NULL; } end: IAMStreamConfig_Release(config); On Thu, Sep 5, 2019 at 2:56 PM Alexey Potakhov wrote: > > re-sending without tabs. > > On Wed, Sep 4, 2019 at 6:22 PM Carl Eugen Hoyos wrote: > > > > Am Do., 5. Sept. 2019 um 00:08 Uhr schrieb Alexey Potakhov > > : > > > > > In some rare cases when IAMStreamConfig_GetStreamCaps returns > > > an error avformat_open_input() crashes with access violation. > > > > Tabs are rejected by our repository, please remove them and resend. > > > > Carl Eugen > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 9/22/16, Roger Pack wrote: > On 1/4/12, Yuval Adam wrote: >> From: Yuval Adam >> >> The image2 muxer now supports timestamps in output filenames. >> When used in an output patterm '%t' will be replaced with the frames >> timestamp in hours, minutes and seconds (hh:mm:ss). > > A somewhat updated (but not yet cleaned up) revision: > > https://gist.github.com/rdp/e518616f2a702367ae5a922b56e09e04 > > see also https://trac.ffmpeg.org/ticket/1452 OK attached is the "cleaned up" patch, ready for review/commit. how to test: (apply then) run this: ./ffmpeg -i input -copyts -vsync vfr temp/abc-%d-%t.jpeg and compare filenames with the timestamps from video packets of ffprobe -show_packets. Probably a better way would have been to mix it into av_bprint_strftime however I wasn't sure how to use that within libavformat/utils.c av_get_frame_filename2 Adam's initial patch (https://github.com/yuvadm/FFmpeg/commit/0eb002821a2076cb3593c823399aeef9fdd29525) also deprecated av_get_frame_filename but I wasn't sure if we wanted that here or not so didn't include it. Thank you for your consideration. -roger- 0001-img2-encoder-allow-t-in-filename-based-on-patch-from.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 10/10/16, Roger Pack wrote: > On 9/22/16, Roger Pack wrote: >> On 1/4/12, Yuval Adam wrote: >>> From: Yuval Adam >>> >>> The image2 muxer now supports timestamps in output filenames. >>> When used in an output patterm '%t' will be replaced with the frames >>> timestamp in hours, minutes and seconds (hh:mm:ss). >> >> A somewhat updated (but not yet cleaned up) revision: >> >> https://gist.github.com/rdp/e518616f2a702367ae5a922b56e09e04 >> >> see also https://trac.ffmpeg.org/ticket/1452 > > OK attached is the "cleaned up" patch, ready for review/commit. > > how to test: > (apply then) run this: > > ./ffmpeg -i input -copyts -vsync vfr temp/abc-%d-%t.jpeg > and compare filenames with the timestamps from video packets of > ffprobe -show_packets. > > Probably a better way would have been to mix it into > av_bprint_strftime however I wasn't sure how to use that within > libavformat/utils.c av_get_frame_filename2 > > Adam's initial patch > (https://github.com/yuvadm/FFmpeg/commit/0eb002821a2076cb3593c823399aeef9fdd29525) > also deprecated av_get_frame_filename > > but I wasn't sure if we wanted that here or not so didn't include it. > Thank you for your consideration. bump (this last one is cleaned up enough to be considered for merge please...). -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: dshow prevent some windows 10 anniv. ed crashes
On 9/5/16, Roger Pack wrote: > On 9/4/16, Carl Eugen Hoyos wrote: >> Hi! >> >> 2016-08-20 12:09 GMT+02:00 Timo Rothenpieler : >>> On 8/19/2016 3:28 PM, Roger Pack wrote: >>>> No complaints, would someone please push it for me? Sorry still >>>> haven't figured out the key thing yet. >>> >>> pushed >> >> Did this fix ticket #5775? OK I heard a rumor microsoft had fixed it on their end, so feel free to close that ticket now. Thanks. > Not entirely, still readying another patch FWIW. > >> Carl Eugen >> ___ >> 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 1/2] img2: added support for %t output pattern
On 10/16/16, Michael Niedermayer wrote:
> On Mon, Oct 10, 2016 at 02:56:24PM -0600, Roger Pack wrote:
>> On 9/22/16, Roger Pack wrote:
>> > On 1/4/12, Yuval Adam wrote:
>> >> From: Yuval Adam
>> >>
>> >> The image2 muxer now supports timestamps in output filenames.
>> >> When used in an output patterm '%t' will be replaced with the frames
>> >> timestamp in hours, minutes and seconds (hh:mm:ss).
>> >
>> > A somewhat updated (but not yet cleaned up) revision:
>> >
>> > https://gist.github.com/rdp/e518616f2a702367ae5a922b56e09e04
>> >
>> > see also https://trac.ffmpeg.org/ticket/1452
>>
>> OK attached is the "cleaned up" patch, ready for review/commit.
>>
>> how to test:
>> (apply then) run this:
>>
>> ./ffmpeg -i input -copyts -vsync vfr temp/abc-%d-%t.jpeg
>> and compare filenames with the timestamps from video packets of
>> ffprobe -show_packets.
>>
>> Probably a better way would have been to mix it into
>> av_bprint_strftime however I wasn't sure how to use that within
>> libavformat/utils.c av_get_frame_filename2
>>
>> Adam's initial patch
>> (https://github.com/yuvadm/FFmpeg/commit/0eb002821a2076cb3593c823399aeef9fdd29525)
>> also deprecated av_get_frame_filename
>>
>> but I wasn't sure if we wanted that here or not so didn't include it.
>> Thank you for your consideration.
>> -roger-
>
>> doc/muxers.texi| 19 ---
>> libavformat/avformat.h |3 ++-
>> libavformat/hlsenc.c |6 +++---
>> libavformat/img2enc.c |7 +--
>> libavformat/utils.c| 36
>> 5 files changed, 58 insertions(+), 13 deletions(-)
>> 06950fc8ba5a9163ffb838a2bff9933e69255b41
>> 0001-img2-encoder-allow-t-in-filename-based-on-patch-from.patch
>> From 11deddfacc595c43a4f542fffe5e90b142e39c85 Mon Sep 17 00:00:00 2001
>> From: rogerdpack
>> Date: Mon, 10 Oct 2016 14:50:20 -0600
>> Subject: [PATCH] img2 encoder: allow %t in filename, based on patch from
>> Yuval
>> Adam
>>
>> Signed-off-by: rogerdpack
>> ---
>> doc/muxers.texi| 19 ---
>> libavformat/avformat.h | 3 ++-
>> libavformat/hlsenc.c | 6 +++---
>> libavformat/img2enc.c | 7 +--
>> libavformat/utils.c| 36
>> 5 files changed, 58 insertions(+), 13 deletions(-)
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index 9ec2e31..6fff966 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d", the
>> first filename of
>> the file list specified will contain the number 1, all the following
>> numbers will be sequential.
>>
>> +If the pattern contains "%t", the frame's timestamps will be inserted
>> +in the filename like "00.00.00.000" for hours, minutes, seconds,
>> +and milliseconds.
>> +
>> +The "%t" and "%d" patterns may be used simultaneously.
>> +
>> The pattern may contain a suffix which is used to automatically
>> determine the format of the image files to write.
>>
>> @@ -635,7 +641,7 @@ The following example shows how to use
>> @command{ffmpeg} for creating a
>> sequence of files @file{img-001.jpeg}, @file{img-002.jpeg}, ...,
>> taking one image every second from the input video:
>> @example
>> -ffmpeg -i in.avi -vsync 1 -r 1 -f image2 'img-%03d.jpeg'
>> +ffmpeg -i in.avi -vsync cfr -r 1 -f image2 'img-%03d.jpeg'
>> @end example
>>
>> Note that with @command{ffmpeg}, if the format is not specified with the
>> @@ -643,12 +649,12 @@ Note that with @command{ffmpeg}, if the format is
>> not specified with the
>> format, the image2 muxer is automatically selected, so the previous
>> command can be written as:
>> @example
>> -ffmpeg -i in.avi -vsync 1 -r 1 'img-%03d.jpeg'
>> +ffmpeg -i in.avi -vsync cfr -r 1 'img-%03d.jpeg'
>> @end example
>>
>> Note also that the pattern must not necessarily contain "%d" or
>> "%0@var{N}d", for example to create a single image file
>> -@file{img.jpeg} from the input video you can employ the command:
>> +@file{img.jpeg} from the start of the input video you can employ the
>> command:
>> @example
>> ffmpeg -i in.avi -f image2 -frames:v 1 img.jpeg
>> @end example
>>
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 10/25/16, Michael Niedermayer wrote:
> On Mon, Oct 24, 2016 at 03:20:14PM -0600, Roger Pack wrote:
>> On 10/16/16, Michael Niedermayer wrote:
>> > On Mon, Oct 10, 2016 at 02:56:24PM -0600, Roger Pack wrote:
>> >> On 9/22/16, Roger Pack wrote:
>> >> > On 1/4/12, Yuval Adam wrote:
>> >> >> From: Yuval Adam
>> >> >>
>> >> >> The image2 muxer now supports timestamps in output filenames.
>> >> >> When used in an output patterm '%t' will be replaced with the
>> >> >> frames
>> >> >> timestamp in hours, minutes and seconds (hh:mm:ss).
>> >> >
>> >> > A somewhat updated (but not yet cleaned up) revision:
>> >> >
>> >> > https://gist.github.com/rdp/e518616f2a702367ae5a922b56e09e04
>> >> >
>> >> > see also https://trac.ffmpeg.org/ticket/1452
>> >>
>> >> OK attached is the "cleaned up" patch, ready for review/commit.
>> >>
>> >> how to test:
>> >> (apply then) run this:
>> >>
>> >> ./ffmpeg -i input -copyts -vsync vfr temp/abc-%d-%t.jpeg
>> >> and compare filenames with the timestamps from video packets of
>> >> ffprobe -show_packets.
>> >>
>> >> Probably a better way would have been to mix it into
>> >> av_bprint_strftime however I wasn't sure how to use that within
>> >> libavformat/utils.c av_get_frame_filename2
>> >>
>> >> Adam's initial patch
>> >> (https://github.com/yuvadm/FFmpeg/commit/0eb002821a2076cb3593c823399aeef9fdd29525)
>> >> also deprecated av_get_frame_filename
>> >>
>> >> but I wasn't sure if we wanted that here or not so didn't include it.
>> >> Thank you for your consideration.
>> >> -roger-
>> >
>> >> doc/muxers.texi| 19 ---
>> >> libavformat/avformat.h |3 ++-
>> >> libavformat/hlsenc.c |6 +++---
>> >> libavformat/img2enc.c |7 +--
>> >> libavformat/utils.c| 36
>> >> 5 files changed, 58 insertions(+), 13 deletions(-)
>> >> 06950fc8ba5a9163ffb838a2bff9933e69255b41
>> >> 0001-img2-encoder-allow-t-in-filename-based-on-patch-from.patch
>> >> From 11deddfacc595c43a4f542fffe5e90b142e39c85 Mon Sep 17 00:00:00 2001
>> >> From: rogerdpack
>> >> Date: Mon, 10 Oct 2016 14:50:20 -0600
>> >> Subject: [PATCH] img2 encoder: allow %t in filename, based on patch
>> >> from
>> >> Yuval
>> >> Adam
>> >>
>> >> Signed-off-by: rogerdpack
>> >> ---
>> >> doc/muxers.texi| 19 ---
>> >> libavformat/avformat.h | 3 ++-
>> >> libavformat/hlsenc.c | 6 +++---
>> >> libavformat/img2enc.c | 7 +--
>> >> libavformat/utils.c| 36
>> >> 5 files changed, 58 insertions(+), 13 deletions(-)
>> >>
>> >> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> >> index 9ec2e31..6fff966 100644
>> >> --- a/doc/muxers.texi
>> >> +++ b/doc/muxers.texi
>> >> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d", the
>> >> first filename of
>> >> the file list specified will contain the number 1, all the following
>> >> numbers will be sequential.
>> >>
>> >> +If the pattern contains "%t", the frame's timestamps will be inserted
>> >> +in the filename like "00.00.00.000" for hours, minutes, seconds,
>> >> +and milliseconds.
>> >> +
>> >> +The "%t" and "%d" patterns may be used simultaneously.
>> >> +
>> >> The pattern may contain a suffix which is used to automatically
>> >> determine the format of the image files to write.
>> >>
>> >> @@ -635,7 +641,7 @@ The following example shows how to use
>> >> @command{ffmpeg} for creating a
>> >> sequence of files @file{img-001.jpeg}, @file{img-002.jpeg}, ...,
>> >> taking one image every second from the input video:
>> >> @example
>> >> -ffmpeg -i in.avi -vsync 1 -r 1 -f image2 'img-%03d.jpeg'
>> >> +ffmpeg -i in.avi -vsync cfr -r 1 -f image2 'img-%03d.jpeg'
>> >> @end example
>> >&
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 10/26/16, Michael Niedermayer wrote:
> On Tue, Oct 25, 2016 at 06:38:12PM -0600, Roger Pack wrote:
>> On 10/25/16, Michael Niedermayer wrote:
>> > On Mon, Oct 24, 2016 at 03:20:14PM -0600, Roger Pack wrote:
>> >> On 10/16/16, Michael Niedermayer wrote:
>> >> > On Mon, Oct 10, 2016 at 02:56:24PM -0600, Roger Pack wrote:
>> >> >> On 9/22/16, Roger Pack wrote:
>> >> >> > On 1/4/12, Yuval Adam wrote:
>> >> >> >> From: Yuval Adam
>> >> >> >>
>> >> >> >> The image2 muxer now supports timestamps in output filenames.
>> >> >> >> When used in an output patterm '%t' will be replaced with the
>> >> >> >> frames
>> >> >> >> timestamp in hours, minutes and seconds (hh:mm:ss).
>> >> >> >
>> >> >> > A somewhat updated (but not yet cleaned up) revision:
>> >> >> >
>> >> >> > https://gist.github.com/rdp/e518616f2a702367ae5a922b56e09e04
>> >> >> >
>> >> >> > see also https://trac.ffmpeg.org/ticket/1452
>> >> >>
>> >> >> OK attached is the "cleaned up" patch, ready for review/commit.
>> >> >>
>> >> >> how to test:
>> >> >> (apply then) run this:
>> >> >>
>> >> >> ./ffmpeg -i input -copyts -vsync vfr temp/abc-%d-%t.jpeg
>> >> >> and compare filenames with the timestamps from video packets of
>> >> >> ffprobe -show_packets.
>> >> >>
>> >> >> Probably a better way would have been to mix it into
>> >> >> av_bprint_strftime however I wasn't sure how to use that within
>> >> >> libavformat/utils.c av_get_frame_filename2
>> >> >>
>> >> >> Adam's initial patch
>> >> >> (https://github.com/yuvadm/FFmpeg/commit/0eb002821a2076cb3593c823399aeef9fdd29525)
>> >> >> also deprecated av_get_frame_filename
>> >> >>
>> >> >> but I wasn't sure if we wanted that here or not so didn't include
>> >> >> it.
>> >> >> Thank you for your consideration.
>> >> >> -roger-
>> >> >
>> >> >> doc/muxers.texi| 19 ---
>> >> >> libavformat/avformat.h |3 ++-
>> >> >> libavformat/hlsenc.c |6 +++---
>> >> >> libavformat/img2enc.c |7 +--
>> >> >> libavformat/utils.c| 36
>> >> >> 5 files changed, 58 insertions(+), 13 deletions(-)
>> >> >> 06950fc8ba5a9163ffb838a2bff9933e69255b41
>> >> >> 0001-img2-encoder-allow-t-in-filename-based-on-patch-from.patch
>> >> >> From 11deddfacc595c43a4f542fffe5e90b142e39c85 Mon Sep 17 00:00:00
>> >> >> 2001
>> >> >> From: rogerdpack
>> >> >> Date: Mon, 10 Oct 2016 14:50:20 -0600
>> >> >> Subject: [PATCH] img2 encoder: allow %t in filename, based on patch
>> >> >> from
>> >> >> Yuval
>> >> >> Adam
>> >> >>
>> >> >> Signed-off-by: rogerdpack
>> >> >> ---
>> >> >> doc/muxers.texi| 19 ---
>> >> >> libavformat/avformat.h | 3 ++-
>> >> >> libavformat/hlsenc.c | 6 +++---
>> >> >> libavformat/img2enc.c | 7 +--
>> >> >> libavformat/utils.c| 36
>> >> >> 5 files changed, 58 insertions(+), 13 deletions(-)
>> >> >>
>> >> >> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> >> >> index 9ec2e31..6fff966 100644
>> >> >> --- a/doc/muxers.texi
>> >> >> +++ b/doc/muxers.texi
>> >> >> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d",
>> >> >> the
>> >> >> first filename of
>> >> >> the file list specified will contain the number 1, all the
>> >> >> following
>> >> >> numbers will be sequential.
>> >> >>
>> >> >> +If the pattern contains "%t", the frame's timestamps will be
>> >> >> inserted
>> >> >> +in the filename like
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 11/1/16, James Almer wrote:
> On 10/25/2016 9:38 PM, Roger Pack wrote:
>> From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17 00:00:00 2001
>> From: rogerdpack
>> Date: Tue, 25 Oct 2016 18:33:12 -0600
>> Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based on patch
>> from
>> Yuval Adam
>>
>> Signed-off-by: rogerdpack
>> ---
>> doc/muxers.texi| 13 +
>> libavformat/avformat.h | 3 ++-
>> libavformat/hlsenc.c | 6 +++---
>> libavformat/img2enc.c | 6 --
>> libavformat/utils.c| 42 ++
>> 5 files changed, 60 insertions(+), 10 deletions(-)
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index 0d856db..0c3a198 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d", the
>> first filename of
>> the file list specified will contain the number 1, all the following
>> numbers will be sequential.
>>
>> +If the pattern contains "%t", the frame's timestamps will be inserted
>> +in the filename like "00.00.00.000" for hours, minutes, seconds,
>> +and milliseconds.
>> +
>> +The "%t" and "%d" patterns may be used simultaneously.
>> +
>> The pattern may contain a suffix which is used to automatically
>> determine the format of the image files to write.
>>
>> @@ -664,6 +670,13 @@ can be used:
>> ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>> "%Y-%m-%d_%H-%M-%S.jpg"
>> @end example
>>
>> +The following example uses the timestamp parameter to generate one
>> +image file per video frame from the input, and name it including its
>> original
>> +timestamp.
>> +@example
>> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>> +@end example
>> +
>> @subsection Options
>>
>> @table @option
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index f9f4d72..7f39698 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -2780,10 +2780,11 @@ void av_dump_format(AVFormatContext *ic,
>> * @param path numbered sequence string
>> * @param number frame number
>> * @param flags AV_FRAME_FILENAME_FLAGS_*
>> + * @param ts frame timestamp in AV_TIME_BASE fractional seconds.
>> * @return 0 if OK, -1 on format error
>> */
>> int av_get_frame_filename2(char *buf, int buf_size,
>> - const char *path, int number, int flags);
>> + const char *path, int number, int flags,
>> int64_t ts);
>
> Uhh, what? did you just break API modifying a public function?
Yes, it was a recently added method so I hoped to get it "included"
before a version was released (but it took so long it maybe missed a
deadline...?)
Cheers!
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 11/1/16, James Almer wrote:
> On 11/1/2016 6:43 PM, James Almer wrote:
>> On 10/25/2016 9:38 PM, Roger Pack wrote:
>>> From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17 00:00:00 2001
>>> From: rogerdpack
>>> Date: Tue, 25 Oct 2016 18:33:12 -0600
>>> Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based on patch
>>> from
>>> Yuval Adam
>>>
>>> Signed-off-by: rogerdpack
>>> ---
>>> doc/muxers.texi| 13 +
>>> libavformat/avformat.h | 3 ++-
>>> libavformat/hlsenc.c | 6 +++---
>>> libavformat/img2enc.c | 6 --
>>> libavformat/utils.c| 42 ++
>>> 5 files changed, 60 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index 0d856db..0c3a198 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d", the
>>> first filename of
>>> the file list specified will contain the number 1, all the following
>>> numbers will be sequential.
>>>
>>> +If the pattern contains "%t", the frame's timestamps will be inserted
>>> +in the filename like "00.00.00.000" for hours, minutes, seconds,
>>> +and milliseconds.
>>> +
>>> +The "%t" and "%d" patterns may be used simultaneously.
>>> +
>>> The pattern may contain a suffix which is used to automatically
>>> determine the format of the image files to write.
>>>
>>> @@ -664,6 +670,13 @@ can be used:
>>> ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>>> "%Y-%m-%d_%H-%M-%S.jpg"
>>> @end example
>>>
>>> +The following example uses the timestamp parameter to generate one
>>> +image file per video frame from the input, and name it including its
>>> original
>>> +timestamp.
>>> +@example
>>> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>>> +@end example
>>> +
>>> @subsection Options
>>>
>>> @table @option
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index f9f4d72..7f39698 100644
>>> --- a/libavformat/avformat.h
>>> +++ b/libavformat/avformat.h
>>> @@ -2780,10 +2780,11 @@ void av_dump_format(AVFormatContext *ic,
>>> * @param path numbered sequence string
>>> * @param number frame number
>>> * @param flags AV_FRAME_FILENAME_FLAGS_*
>>> + * @param ts frame timestamp in AV_TIME_BASE fractional seconds.
>>> * @return 0 if OK, -1 on format error
>>> */
>>> int av_get_frame_filename2(char *buf, int buf_size,
>>> - const char *path, int number, int flags);
>>> + const char *path, int number, int flags,
>>> int64_t ts);
>>
>> Uhh, what? did you just break API modifying a public function?
>>
>
> For the record, this was reverted.
>
> Shouldn't be hard to solve, i think. Just add a new ff_get_frame_filename()
> function to internal.h with this new signature, at least for now and for
> this
> feature, to avoid adding a third public function doing the same thing unless
> absolutely necessary.
OK see attached. Wasn't sure if I should duplicate docs or not, feel
free to modify.
Cheers!
-roger-
0001-img2-encoder-allow-t-in-filepattern-based-on-patch-f.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '7a745f014f528d1001394ae4d2f4ed1a20bf7fa2'
On 11/14/16, James Almer wrote: > On 11/14/2016 8:01 AM, Michael Niedermayer wrote: >> On Sun, Nov 13, 2016 at 10:32:13PM +0100, Hendrik Leppkes wrote: >>> ffmpeg | branch: master | Hendrik Leppkes | Sun Nov >>> 13 22:29:04 2016 +0100| [bd0db4a32d85d027da4d4dc00490c20048090312] | >>> committer: Hendrik Leppkes >>> >>> Merge commit '7a745f014f528d1001394ae4d2f4ed1a20bf7fa2' >>> >>> * commit '7a745f014f528d1001394ae4d2f4ed1a20bf7fa2': >>> options_table: Add aliases for color properties >>> >>> Merged-by: Hendrik Leppkes >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=bd0db4a32d85d027da4d4dc00490c20048090312 >>> --- >>> >>> libavcodec/options_table.h | 32 >>> libavcodec/version.h | 2 +- >>> 2 files changed, 25 insertions(+), 9 deletions(-) >> >> Please dont forget to add documentation for every option you add. > > Done. > >> IIRC Libav has code to automatically generate documentation from >> AVOptions. Several FFmpeg developers objected against enabling that >> code. IIRC because hand written documentation is of much higher quality > > Automatically generated documentation for options like this sounds very > useful. I don't know why it was rejected. There's not much more "quality" > to be had over manually written lines for AVOptions. +1 from me, plus help avoid a bit of duplication. My only concern is that AVOptions today feel like "one liner" documentation, maybe some option could be added there for more verbose descriptions within the AVOptions or some odd... :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 11/10/16, Roger Pack wrote:
> On 11/1/16, James Almer wrote:
>> On 11/1/2016 6:43 PM, James Almer wrote:
>>> On 10/25/2016 9:38 PM, Roger Pack wrote:
>>>> From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17 00:00:00 2001
>>>> From: rogerdpack
>>>> Date: Tue, 25 Oct 2016 18:33:12 -0600
>>>> Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based on patch
>>>> from
>>>> Yuval Adam
>>>>
>>>> Signed-off-by: rogerdpack
>>>> ---
>>>> doc/muxers.texi| 13 +
>>>> libavformat/avformat.h | 3 ++-
>>>> libavformat/hlsenc.c | 6 +++---
>>>> libavformat/img2enc.c | 6 --
>>>> libavformat/utils.c| 42 ++
>>>> 5 files changed, 60 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>>> index 0d856db..0c3a198 100644
>>>> --- a/doc/muxers.texi
>>>> +++ b/doc/muxers.texi
>>>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d", the
>>>> first filename of
>>>> the file list specified will contain the number 1, all the following
>>>> numbers will be sequential.
>>>>
>>>> +If the pattern contains "%t", the frame's timestamps will be inserted
>>>> +in the filename like "00.00.00.000" for hours, minutes, seconds,
>>>> +and milliseconds.
>>>> +
>>>> +The "%t" and "%d" patterns may be used simultaneously.
>>>> +
>>>> The pattern may contain a suffix which is used to automatically
>>>> determine the format of the image files to write.
>>>>
>>>> @@ -664,6 +670,13 @@ can be used:
>>>> ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>>>> "%Y-%m-%d_%H-%M-%S.jpg"
>>>> @end example
>>>>
>>>> +The following example uses the timestamp parameter to generate one
>>>> +image file per video frame from the input, and name it including its
>>>> original
>>>> +timestamp.
>>>> +@example
>>>> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>>>> +@end example
>>>> +
>>>> @subsection Options
>>>>
>>>> @table @option
>>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>>> index f9f4d72..7f39698 100644
>>>> --- a/libavformat/avformat.h
>>>> +++ b/libavformat/avformat.h
>>>> @@ -2780,10 +2780,11 @@ void av_dump_format(AVFormatContext *ic,
>>>> * @param path numbered sequence string
>>>> * @param number frame number
>>>> * @param flags AV_FRAME_FILENAME_FLAGS_*
>>>> + * @param ts frame timestamp in AV_TIME_BASE fractional seconds.
>>>> * @return 0 if OK, -1 on format error
>>>> */
>>>> int av_get_frame_filename2(char *buf, int buf_size,
>>>> - const char *path, int number, int flags);
>>>> + const char *path, int number, int flags,
>>>> int64_t ts);
>>>
>>> Uhh, what? did you just break API modifying a public function?
>>>
>>
>> For the record, this was reverted.
>>
>> Shouldn't be hard to solve, i think. Just add a new
>> ff_get_frame_filename()
>> function to internal.h with this new signature, at least for now and for
>> this
>> feature, to avoid adding a third public function doing the same thing
>> unless
>> absolutely necessary.
>
> OK see attached. Wasn't sure if I should duplicate docs or not, feel
> free to modify.
Ping...if no response in another few days I'll go ahead and get write
access and commit it myself.
Thanks.
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 11/15/16, James Almer wrote:
> On 11/10/2016 4:26 PM, Roger Pack wrote:
>> On 11/1/16, James Almer wrote:
>>> > On 11/1/2016 6:43 PM, James Almer wrote:
>>>> >> On 10/25/2016 9:38 PM, Roger Pack wrote:
>>>>> >>> From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17 00:00:00
>>>>> >>> 2001
>>>>> >>> From: rogerdpack
>>>>> >>> Date: Tue, 25 Oct 2016 18:33:12 -0600
>>>>> >>> Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based on
>>>>> >>> patch
>>>>> >>> from
>>>>> >>> Yuval Adam
>>>>> >>>
>>>>> >>> Signed-off-by: rogerdpack
>>>>> >>> ---
>>>>> >>> doc/muxers.texi| 13 +
>>>>> >>> libavformat/avformat.h | 3 ++-
>>>>> >>> libavformat/hlsenc.c | 6 +++---
>>>>> >>> libavformat/img2enc.c | 6 --
>>>>> >>> libavformat/utils.c| 42
>>>>> >>> ++
>>>>> >>> 5 files changed, 60 insertions(+), 10 deletions(-)
>>>>> >>>
>>>>> >>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>>>> >>> index 0d856db..0c3a198 100644
>>>>> >>> --- a/doc/muxers.texi
>>>>> >>> +++ b/doc/muxers.texi
>>>>> >>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d",
>>>>> >>> the
>>>>> >>> first filename of
>>>>> >>> the file list specified will contain the number 1, all the
>>>>> >>> following
>>>>> >>> numbers will be sequential.
>>>>> >>>
>>>>> >>> +If the pattern contains "%t", the frame's timestamps will be
>>>>> >>> inserted
>>>>> >>> +in the filename like "00.00.00.000" for hours, minutes, seconds,
>>>>> >>> +and milliseconds.
>>>>> >>> +
>>>>> >>> +The "%t" and "%d" patterns may be used simultaneously.
>>>>> >>> +
>>>>> >>> The pattern may contain a suffix which is used to automatically
>>>>> >>> determine the format of the image files to write.
>>>>> >>>
>>>>> >>> @@ -664,6 +670,13 @@ can be used:
>>>>> >>> ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>>>>> >>> "%Y-%m-%d_%H-%M-%S.jpg"
>>>>> >>> @end example
>>>>> >>>
>>>>> >>> +The following example uses the timestamp parameter to generate one
>>>>> >>> +image file per video frame from the input, and name it including
>>>>> >>> its
>>>>> >>> original
>>>>> >>> +timestamp.
>>>>> >>> +@example
>>>>> >>> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>>>>> >>> +@end example
>>>>> >>> +
>>>>> >>> @subsection Options
>>>>> >>>
>>>>> >>> @table @option
>>>>> >>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>>>> >>> index f9f4d72..7f39698 100644
>>>>> >>> --- a/libavformat/avformat.h
>>>>> >>> +++ b/libavformat/avformat.h
>>>>> >>> @@ -2780,10 +2780,11 @@ void av_dump_format(AVFormatContext *ic,
>>>>> >>> * @param path numbered sequence string
>>>>> >>> * @param number frame number
>>>>> >>> * @param flags AV_FRAME_FILENAME_FLAGS_*
>>>>> >>> + * @param ts frame timestamp in AV_TIME_BASE fractional seconds.
>>>>> >>> * @return 0 if OK, -1 on format error
>>>>> >>> */
>>>>> >>> int av_get_frame_filename2(char *buf, int buf_size,
>>>>> >>> - const char *path, int number, int
>>>>> >>> flags);
>>>>> >>> + const char *path, int number, int flags,
>>>>> >>> int64
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 11/18/16, Roger Pack wrote:
> On 11/15/16, James Almer wrote:
>> On 11/10/2016 4:26 PM, Roger Pack wrote:
>>> On 11/1/16, James Almer wrote:
>>>> > On 11/1/2016 6:43 PM, James Almer wrote:
>>>>> >> On 10/25/2016 9:38 PM, Roger Pack wrote:
>>>>>> >>> From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17 00:00:00
>>>>>> >>> 2001
>>>>>> >>> From: rogerdpack
>>>>>> >>> Date: Tue, 25 Oct 2016 18:33:12 -0600
>>>>>> >>> Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based on
>>>>>> >>> patch
>>>>>> >>> from
>>>>>> >>> Yuval Adam
>>>>>> >>>
>>>>>> >>> Signed-off-by: rogerdpack
>>>>>> >>> ---
>>>>>> >>> doc/muxers.texi| 13 +
>>>>>> >>> libavformat/avformat.h | 3 ++-
>>>>>> >>> libavformat/hlsenc.c | 6 +++---
>>>>>> >>> libavformat/img2enc.c | 6 --
>>>>>> >>> libavformat/utils.c| 42
>>>>>> >>> ++
>>>>>> >>> 5 files changed, 60 insertions(+), 10 deletions(-)
>>>>>> >>>
>>>>>> >>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>>>>> >>> index 0d856db..0c3a198 100644
>>>>>> >>> --- a/doc/muxers.texi
>>>>>> >>> +++ b/doc/muxers.texi
>>>>>> >>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or
>>>>>> >>> "%0@var{N}d",
>>>>>> >>> the
>>>>>> >>> first filename of
>>>>>> >>> the file list specified will contain the number 1, all the
>>>>>> >>> following
>>>>>> >>> numbers will be sequential.
>>>>>> >>>
>>>>>> >>> +If the pattern contains "%t", the frame's timestamps will be
>>>>>> >>> inserted
>>>>>> >>> +in the filename like "00.00.00.000" for hours, minutes, seconds,
>>>>>> >>> +and milliseconds.
>>>>>> >>> +
>>>>>> >>> +The "%t" and "%d" patterns may be used simultaneously.
>>>>>> >>> +
>>>>>> >>> The pattern may contain a suffix which is used to automatically
>>>>>> >>> determine the format of the image files to write.
>>>>>> >>>
>>>>>> >>> @@ -664,6 +670,13 @@ can be used:
>>>>>> >>> ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>>>>>> >>> "%Y-%m-%d_%H-%M-%S.jpg"
>>>>>> >>> @end example
>>>>>> >>>
>>>>>> >>> +The following example uses the timestamp parameter to generate
>>>>>> >>> one
>>>>>> >>> +image file per video frame from the input, and name it including
>>>>>> >>> its
>>>>>> >>> original
>>>>>> >>> +timestamp.
>>>>>> >>> +@example
>>>>>> >>> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>>>>>> >>> +@end example
>>>>>> >>> +
>>>>>> >>> @subsection Options
>>>>>> >>>
>>>>>> >>> @table @option
>>>>>> >>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>>>>> >>> index f9f4d72..7f39698 100644
>>>>>> >>> --- a/libavformat/avformat.h
>>>>>> >>> +++ b/libavformat/avformat.h
>>>>>> >>> @@ -2780,10 +2780,11 @@ void av_dump_format(AVFormatContext *ic,
>>>>>> >>> * @param path numbered sequence string
>>>>>> >>> * @param number frame number
>>>>>> >>> * @param flags AV_FRAME_FILENAME_FLAGS_*
>>>>>> >>> + * @param ts frame timestamp in AV_TIME_BASE fractional seconds.
>>>>>> >>> * @return 0 if OK, -1 on format error
>
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 11/25/16, Roger Pack wrote:
> On 11/18/16, Roger Pack wrote:
>> On 11/15/16, James Almer wrote:
>>> On 11/10/2016 4:26 PM, Roger Pack wrote:
>>>> On 11/1/16, James Almer wrote:
>>>>> > On 11/1/2016 6:43 PM, James Almer wrote:
>>>>>> >> On 10/25/2016 9:38 PM, Roger Pack wrote:
>>>>>>> >>> From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17
>>>>>>> >>> 00:00:00
>>>>>>> >>> 2001
>>>>>>> >>> From: rogerdpack
>>>>>>> >>> Date: Tue, 25 Oct 2016 18:33:12 -0600
>>>>>>> >>> Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based
>>>>>>> >>> on
>>>>>>> >>> patch
>>>>>>> >>> from
>>>>>>> >>> Yuval Adam
>>>>>>> >>>
>>>>>>> >>> Signed-off-by: rogerdpack
>>>>>>> >>> ---
>>>>>>> >>> doc/muxers.texi| 13 +
>>>>>>> >>> libavformat/avformat.h | 3 ++-
>>>>>>> >>> libavformat/hlsenc.c | 6 +++---
>>>>>>> >>> libavformat/img2enc.c | 6 --
>>>>>>> >>> libavformat/utils.c| 42
>>>>>>> >>> ++
>>>>>>> >>> 5 files changed, 60 insertions(+), 10 deletions(-)
>>>>>>> >>>
>>>>>>> >>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>>>>>> >>> index 0d856db..0c3a198 100644
>>>>>>> >>> --- a/doc/muxers.texi
>>>>>>> >>> +++ b/doc/muxers.texi
>>>>>>> >>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or
>>>>>>> >>> "%0@var{N}d",
>>>>>>> >>> the
>>>>>>> >>> first filename of
>>>>>>> >>> the file list specified will contain the number 1, all the
>>>>>>> >>> following
>>>>>>> >>> numbers will be sequential.
>>>>>>> >>>
>>>>>>> >>> +If the pattern contains "%t", the frame's timestamps will be
>>>>>>> >>> inserted
>>>>>>> >>> +in the filename like "00.00.00.000" for hours, minutes,
>>>>>>> >>> seconds,
>>>>>>> >>> +and milliseconds.
>>>>>>> >>> +
>>>>>>> >>> +The "%t" and "%d" patterns may be used simultaneously.
>>>>>>> >>> +
>>>>>>> >>> The pattern may contain a suffix which is used to automatically
>>>>>>> >>> determine the format of the image files to write.
>>>>>>> >>>
>>>>>>> >>> @@ -664,6 +670,13 @@ can be used:
>>>>>>> >>> ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>>>>>>> >>> "%Y-%m-%d_%H-%M-%S.jpg"
>>>>>>> >>> @end example
>>>>>>> >>>
>>>>>>> >>> +The following example uses the timestamp parameter to generate
>>>>>>> >>> one
>>>>>>> >>> +image file per video frame from the input, and name it
>>>>>>> >>> including
>>>>>>> >>> its
>>>>>>> >>> original
>>>>>>> >>> +timestamp.
>>>>>>> >>> +@example
>>>>>>> >>> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>>>>>>> >>> +@end example
>>>>>>> >>> +
>>>>>>> >>> @subsection Options
>>>>>>> >>>
>>>>>>> >>> @table @option
>>>>>>> >>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>>>>>> >>> index f9f4d72..7f39698 100644
>>>>>>> >>> --- a/libavformat/avformat.h
>>>>>>> >>> +++ b/libavformat/avformat.h
>>>>>>> >>>
Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern
On 12/2/16, James Almer wrote:
> On 12/2/2016 10:06 PM, Roger Pack wrote:
>> On 11/25/16, Roger Pack wrote:
>>> On 11/18/16, Roger Pack wrote:
>>>> On 11/15/16, James Almer wrote:
>>>>> On 11/10/2016 4:26 PM, Roger Pack wrote:
>>>>>> On 11/1/16, James Almer wrote:
>>>>>>>> On 11/1/2016 6:43 PM, James Almer wrote:
>>>>>>>>>> On 10/25/2016 9:38 PM, Roger Pack wrote:
>>>>>>>>>>>> From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17
>>>>>>>>>>>> 00:00:00
>>>>>>>>>>>> 2001
>>>>>>>>>>>> From: rogerdpack
>>>>>>>>>>>> Date: Tue, 25 Oct 2016 18:33:12 -0600
>>>>>>>>>>>> Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based
>>>>>>>>>>>> on
>>>>>>>>>>>> patch
>>>>>>>>>>>> from
>>>>>>>>>>>> Yuval Adam
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: rogerdpack
>>>>>>>>>>>> ---
>>>>>>>>>>>> doc/muxers.texi| 13 +
>>>>>>>>>>>> libavformat/avformat.h | 3 ++-
>>>>>>>>>>>> libavformat/hlsenc.c | 6 +++---
>>>>>>>>>>>> libavformat/img2enc.c | 6 --
>>>>>>>>>>>> libavformat/utils.c| 42
>>>>>>>>>>>> ++
>>>>>>>>>>>> 5 files changed, 60 insertions(+), 10 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>>>>>>>>>>> index 0d856db..0c3a198 100644
>>>>>>>>>>>> --- a/doc/muxers.texi
>>>>>>>>>>>> +++ b/doc/muxers.texi
>>>>>>>>>>>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or
>>>>>>>>>>>> "%0@var{N}d",
>>>>>>>>>>>> the
>>>>>>>>>>>> first filename of
>>>>>>>>>>>> the file list specified will contain the number 1, all the
>>>>>>>>>>>> following
>>>>>>>>>>>> numbers will be sequential.
>>>>>>>>>>>>
>>>>>>>>>>>> +If the pattern contains "%t", the frame's timestamps will be
>>>>>>>>>>>> inserted
>>>>>>>>>>>> +in the filename like "00.00.00.000" for hours, minutes,
>>>>>>>>>>>> seconds,
>>>>>>>>>>>> +and milliseconds.
>>>>>>>>>>>> +
>>>>>>>>>>>> +The "%t" and "%d" patterns may be used simultaneously.
>>>>>>>>>>>> +
>>>>>>>>>>>> The pattern may contain a suffix which is used to automatically
>>>>>>>>>>>> determine the format of the image files to write.
>>>>>>>>>>>>
>>>>>>>>>>>> @@ -664,6 +670,13 @@ can be used:
>>>>>>>>>>>> ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>>>>>>>>>>>> "%Y-%m-%d_%H-%M-%S.jpg"
>>>>>>>>>>>> @end example
>>>>>>>>>>>>
>>>>>>>>>>>> +The following example uses the timestamp parameter to generate
>>>>>>>>>>>> one
>>>>>>>>>>>> +image file per video frame from the input, and name it
>>>>>>>>>>>> including
>>>>>>>>>>>> its
>>>>>>>>>>>> original
>>>>>>>>>>>> +timestamp.
>>>>>>>>>>>> +@example
>>>>>>>>>>>> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>>>>>>>>>>>> +@end example
>>>>&g
Re: [FFmpeg-devel] Changing media formats mid stream
On 8/24/15, Michael Niedermayer wrote: > On Mon, Aug 24, 2015 at 10:55:07PM +0200, Máté Sebők wrote: >> Oops, forgot to mention, in dshow_pin.c the libAVPin_QueryAccept() have >> to >> be edited to almost the same as libAVPin_ReceiveConnection() just without >> the pin management. > > maybe roger or others can help, i dont have a windows box here nor > do i really know dshow For followers, we ended up working around this by sending a "raw stream" (like URLProtocol) to FFmpeg, that way the stream itself describes the video formats, and they never change. The weird dshow way of doing this is that you set up the graph 'as if" it were always mpeg2video, then when you "start" the graph, it calls for a renegotiation. Weird. >> >> On Mon, Aug 24, 2015 at 10:44 PM, Máté Sebők >> wrote: >> >> > I did a dirty little hack to attempt to fix it. >> > Don't call the dshow_add_device() just in build time, but run the graph >> > and sleep() a bit, then call dshow_add_device() at the end of the >> > dshow_read_header(). >> > >> > Sadly, it does not work, it does not goes beyond the dshow "chit-chat" >> > between filters/pins. >> > >> > After ctrl+c however the right codec stats are displayed... >> > >> > Regards, >> > Máté >> > >> > >> > On Mon, Aug 24, 2015 at 10:29 PM, Michael Niedermayer < >> > mich...@niedermayer.cc> wrote: >> > >> >> On Mon, Aug 24, 2015 at 02:09:28PM -0600, Roger Pack wrote: >> >> > I've run into the case today where (if we understand it correctly) >> >> > you >> >> > setup a directshow graph, it advertises media types, then when you >> >> > "start" the graph, it actually calls through and says "here's your >> >> > *real* media type". >> >> > Does ffmpeg internals have any concept of or support for a "changing >> >> > media type" at runtime? (any other suggestions for how to handle >> >> > this >> >> > if it doesn't?) >> >> >> >> do i understand correctly that the type at read_header() stage is >> >> wrong but the type later at read_packet() stage is correct ? >> >> if that is the case, you can just wait with setting the type till it >> >> is reliably known. >> >> >> >> [...] >> >> -- >> >> Michael GnuPG fingerprint: >> >> 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> >> >> I have never wished to cater to the crowd; for what I know they do not >> >> approve, and what they approve I do not know. -- Epicurus >> >> >> >> ___ >> >> 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 > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > While the State exists there can be no freedom; when there is freedom there > will be no State. -- Vladimir Lenin > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress
As a quick follow up, there is a full working example (windows DTV [ATSC/DVBT/DVBS], works with MPEG or H264 streams, capture channels *with their subchannels* all at once) https://github.com/rdp/ffmpeg/tree/dtv_protocol It uses the "schizo" way where digital TV comes in as a "protocol" from libavformat, and the rest is via normal libavdevice device (suggestions welcome still there...I want to be able to send "raw" mpeg streams to FFmpeg so that it can use its selectors on it, but send that in from a device...wish there were an option for a libavdevice to send "raw" stream-like data :| ). ATSC usage example: https://github.com/rdp/FFmpeg/blob/dtv_protocol/go_protocol_local.bat DVB example: https://github.com/rdp/FFmpeg/blob/dtv_protocol/ffmpeg_dvbt.bat I haven't had the umph to get something ready for merging yet, just linking it in case it's useful to someone in the meantime. Cheers! On 5/28/16, Roger Pack wrote: > On 12/29/15, Hendrik Leppkes wrote: >> On Wed, Dec 30, 2015 at 12:33 AM, Hendrik Leppkes >> wrote: >>> On Wed, Dec 30, 2015 at 12:23 AM, Roger Pack >>> wrote: >>>>> OK I had this great idea to capture the incoming MPEG2 transport >>>>> stream from the digital TV capture device. Kind of like "raw" stream, >>>>> so FFmpeg could have access to, for instance, all the audio stream. >>>>> >>>>> It appears that the type coming out of the tuner is: >>>>> MEDIATYPE_Stream >>>>> with subtype >>>>> KSDATAFORMAT_SUBTYPE_BDA_MPEG2_TRANSPORT >>>>> which is apparently treated the same as MEDIASUBTYPE_MPEG2_TRANSPORT >>>>> by the built in directshow mpeg demuxer [1] so I assume is some kind >>>>> of typical MPEG2 TS stream. >>>>> >>>>> I had hoped that if I set dshow's AVStream's codec_id to >>>>> codec->codec_id = AV_CODEC_ID_NONE; >>>>> codec->codec_type = AVMEDIA_TYPE_DATA; >>>> >>>> Oops that was meant to be >>>> >>>> codec->codec_id = AV_CODEC_ID_MPEG2TS; >>>> codec->codec_type = AVMEDIA_TYPE_DATA; >>>> >>>>> That it would somehow recognize that I was sending it an MPEG stream >>>>> and insert an appropriate demuxer for me. >>>>> >>>>> However, when I run it, it fails like this: >>>>> >>>>> Input #0, dshow, from 'video=Hauppauge WinTV 885 BDA Tuner/Demod': >>>>> Duration: N/A, bitrate: N/A >>>>> Codec 0x2 is not in the full list. >>>>> Stream #0:0, 0, 1/2700: Data: unknown_codec, 0/1 >>>>> Successfully opened the file. >>>>> Output #0, mp4, to 'yo.mp4': >>>>> Output file #0 does not contain any stream >>>>> >>>>> so it's definitely not, for instance, doing a probe or analyze on the >>>>> MPEG stream >>>>> >>>>> Is this possible or any hints/tips/tricks I could possibly use? >>>> >>>> To answer my own question, I turned the dshow capture device into both >>>> an AVInputFormat *and* a URLProtocol that "wraps" the AVInputFormat. >>>> Apparently ffmpeg can receive "raw" bytes only from URLProtocol (?) >>>> This way worked great both "segmented" MPEG2VIDEO streams as well as >>>> "raw" MPEG TS streams. >>>> >>> >>> You should probably just make it use the mpegts demuxer directly, say >>> like the rtsp demuxer. >>> We have an API for that in the form of avpriv_mpegts_parse_packet >>> >>> Making an input device a protocol seems rather ugly, the user needs to >>> know beforehand how to call it that way. > > > True, I wish I didn't have to do it (ex: use AV_CODEC_ID_MPEG2TS and > it "just work" -- any hints or clues to that welcome!) I'd like to > give them access to the command line demultiplexing options that raw > MPEG streams currently have. > > (ex: if they want 3 streams out of 10, like > https://trac.ffmpeg.org/wiki/Map#Example8) without having to build > that functionality into dshow parameters as well. > > >> Or as an alternative, why not just add the mpegts demuxer to the DShow >> graph as well and directly get video/audio streams. >> For Live TV functionality, the MS demuxer seems to be working quite well. > > Mostly so that they can record a channel and its sibling sub channels > (from the same card) all at once, which can be convenient at times. > > Cheers! > -roger- > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] PATCH: dshow prevent some windows 10 anniv. ed crashes
Windows 10 anniversary edition screwed with how dshow video capture works. This patch "helps" in some instances, though it still crashes with rgb24 input (still working on that), at least now it works with yuvp etc. Thanks. -Roger (a dshow maintainer) 0001-dshow-satisfy-alloc-contract-better-prevent-non-rgb2.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avisynth: support pix_fmts added to AviSynth+
Does this require some version check in configure to be added as well? On 8/16/16, Michael Niedermayer wrote: > On Mon, Aug 15, 2016 at 12:37:31PM -0400, Stephen Hutchinson wrote: >> A number of new pix_fmts have been added to AviSynth+: >> 16-bit packed RGB and RGBA >> 10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4 >> 8-, 10-, 12-, 14-, and 16-bit Planar RGB >> 8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA* >> 10-, 12-, 14-, and 16-bit GRAY variants* >> 32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY* >> >> *some of which are not currently available pix_fmts here and were >> not added to the demuxer due to this >> --- >> libavformat/avisynth.c | 176 >> - >> 1 file changed, 175 insertions(+), 1 deletion(-) > > breaks build > > libavformat/avisynth.c:100:40: error: ‘AVS_PLANAR_G’ undeclared here (not in > a function) > libavformat/avisynth.c:100:54: error: ‘AVS_PLANAR_B’ undeclared here (not in > a function) > libavformat/avisynth.c:101:43: error: ‘AVS_PLANAR_R’ undeclared here (not in > a function) > libavformat/avisynth.c:103:57: error: ‘AVS_PLANAR_A’ undeclared here (not in > a function) > libavformat/avisynth.c: In function ‘avisynth_read_packet_video’: > libavformat/avisynth.c:686:36: error: ‘AviSynthLibrary’ has no member named > ‘avs_is_planar_rgb’ > libavformat/avisynth.c:687:36: error: ‘AviSynthLibrary’ has no member named > ‘avs_is_planar_rgba’ > make: *** [libavformat/avisynth.o] Error 1 > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Rewriting code that is poorly written but fully understood is good. > Rewriting code that one doesnt understand is a sign that one is less smart > then the original author, trying to rewrite it will not make it better. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better
On 4/10/16, Michael Niedermayer wrote: > On Sun, Apr 10, 2016 at 07:29:05PM +0100, Rostislav Pehlivanov wrote: >> On 10 April 2016 at 17:42, Michael Niedermayer >> wrote: >> >> > On Sun, Apr 10, 2016 at 04:38:35PM +0100, Kieran Kunhya wrote: >> > > --- >> > > Changelog | 1 + >> > > configure | 6 -- >> > > doc/encoders.texi | 105 - >> > > doc/ffserver.conf | 2 +- >> > > doc/general.texi | 2 +- >> > > doc/muxers.texi| 4 +- >> > > doc/platform.texi | 2 +- >> > > libavcodec/Makefile| 1 - >> > > libavcodec/allcodecs.c | 1 - >> > > libavcodec/libfaac.c | 248 >> > - >> > > libavcodec/version.h | 2 +- >> > > 11 files changed, 7 insertions(+), 367 deletions(-) >> > > delete mode 100644 libavcodec/libfaac.c >> > >> > this is not possible currently libfaac is twice as fast than the >> > native encoder. >> > >> > time ./ffmpeg -v 0 -i matrixbench_mpeg2.mpg -vn -c:a libfaac -y >> > test.aac >> > real0m2.828s >> > user0m2.776s >> > sys 0m0.048s >> > >> > time ./ffmpeg -v 0 -i matrixbench_mpeg2.mpg -vn -y test.aac >> > real0m5.908s >> > user0m5.856s >> > sys 0m0.048s >> > >> > >> > >> FAAC isn't maintained, hasn't had any work done on it in who knows how >> many >> years, nobody but people who don't know that the native encoder/fdk is >> better use it (just a few thankfully), isn't particularly stable >> (segfaulted a few times when I was comparing it last year) and finally, >> it's not good at all. >> An argument that it's faster than the native encoder has as much weight >> as >> an argument that libaac_plus was also faster than the native encoder, >> which >> didn't matter as it was eventually removed >> The age where we needed a few different AAC encoders because there wasn't >> really a single good multipurpose one is gone now. The times have changed >> since FAAC was developed (Nokia sponsored at lot of its development, and >> you know what they used to make) and so have the computers. What was an >> acceptable speed back then for encoding a file at a given quality isn't >> necessarily the same now. And considering that fdk-aac can run as slow as >> our encoder I'd say we're doing pretty well as far as the balance between >> speed and quality goes. > > x264 can encode at really impressive speed and also at really > impressive quality, its the users choice by using teh preset option > > for aac the user can choose speed through using the libfaac encoder > or quality through using the native encoder > speed matters for battery powered devices, not just for media servers > on phones but also for plain audio recording on phones which i think > is more common. FWIW I once received a report that the old (now removed) vo-aacenc was lightning fast. Anybody have any speed/quality comparisons out there? :) -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Compile using bash in Win10 anniversary?
On 8/13/16, Timo Rothenpieler wrote: > On 8/12/2016 8:12 PM, Dan Haddix wrote: >> Can you cross compile ffmpeg for Windows using the new bash built in to >> Win10 anniversary? I'm currently using MinGW but it seems like it might be >> easier to use the built in bash if possible. However I tried a basic >> build, using the same commands I do in MinGW, and it fails. So I assume >> there is something I need to do or setup to make it work, but I'm not sure >> what as my knowledge of Linux is very limited. (I followed a guide to >> setup MinGW) > > The bash for windows contains a full and native Ubuntu userland. > So if you compile ffmpeg in there, you end up with an ELF binary for > Linux, just as if you'd have compiled on an actual Ubuntu Linux. Yeah, he mentioned cross compiling. Anyway I have heard reports back from users saying they have successfully used it for cross compilation, FWIW (haven't tried it myself...). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: dshow prevent some windows 10 anniv. ed crashes
No complaints, would someone please push it for me? Sorry still haven't figured out the key thing yet. On 8/16/16, Roger Pack wrote: > Windows 10 anniversary edition screwed with how dshow video capture works. > This patch "helps" in some instances, though it still crashes with > rgb24 input (still working on that), at least now it works with yuvp > etc. > Thanks. > -Roger (a dshow maintainer) > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: dshow prevent some windows 10 anniv. ed crashes
On 9/4/16, Carl Eugen Hoyos wrote: > Hi! > > 2016-08-20 12:09 GMT+02:00 Timo Rothenpieler : >> On 8/19/2016 3:28 PM, Roger Pack wrote: >>> No complaints, would someone please push it for me? Sorry still >>> haven't figured out the key thing yet. >> >> pushed > > Did this fix ticket #5775? Not entirely, still readying another patch FWIW. > Carl Eugen > ___ > 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 1/2] img2: added support for %t output pattern
On 1/4/12, Yuval Adam wrote: > From: Yuval Adam > > The image2 muxer now supports timestamps in output filenames. > When used in an output patterm '%t' will be replaced with the frames > timestamp in hours, minutes and seconds (hh:mm:ss). A somewhat updated (but not yet cleaned up) revision: https://gist.github.com/rdp/e518616f2a702367ae5a922b56e09e04 see also https://trac.ffmpeg.org/ticket/1452 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.
On 1/25/16, Hendrik Leppkes wrote:
> On Mon, Jan 25, 2016 at 1:13 PM, Michael Niedermayer
> wrote:
>> On Mon, Jan 25, 2016 at 10:24:36AM +, Carl Eugen Hoyos wrote:
>>> Kieran Kunhya kunhya.com> writes:
>>>
>>> > The internal encoder is superior to libvo-aacenc.
>>>
>>> I thought this was the case for several years?
>>>
>>> Needs a Changelog entry and a news entry together with
>>> libaacplus.
>>
>> how does the speed of all the aac encoders compare ?
>> we should keep the fastest and the one havng best quality per bit
>> (assuming thats a single one and not multiple due to different behavior
>> at different bitrates)
>>
>> also it may make sense to keep activly developed encoders so users and
>> develoeprs can continue to test/compare and use them in case they
>> improve
>>
>
>
> libvo-aacenc is a dump from an earlier Android build. Android has
> since switched to fdk-aac and libvo-aacenc is just dead.
> So from that perspective, there is definitely nothing lost.
>
> Can't judge the speed, but libvo-aacenc has the worst quality of all
> aac lc encoders we had, so I doubt anyone is going to miss it.
For some reason this person:
https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=5&t=1457
Missed it ("it's 4x slower!")...
FWIW.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/dshow_crossbar: remove trailing whitespace
On 3/26/16, Lou Logan wrote:
> Signed-off-by: Lou Logan
> ---
> Probably don't need to send this for review, but I know nothing of dshow
> and can't test this trivial change since I don't use Windows.
> ---
> libavdevice/dshow_crossbar.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavdevice/dshow_crossbar.c b/libavdevice/dshow_crossbar.c
> index c0739da..95fb466 100644
> --- a/libavdevice/dshow_crossbar.c
> +++ b/libavdevice/dshow_crossbar.c
> @@ -167,7 +167,7 @@ dshow_try_setup_crossbar_options(ICaptureGraphBuilder2
> *graph_builder2,
> }
>
> if (devtype == VideoDevice && ctx->show_analog_tv_tuner_dialog) {
> -hr = ICaptureGraphBuilder2_FindInterface(graph_builder2,
> &LOOK_UPSTREAM_ONLY, NULL,
> +hr = ICaptureGraphBuilder2_FindInterface(graph_builder2,
> &LOOK_UPSTREAM_ONLY, NULL,
LGTM.
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] dshow: Add missing library dependency (dxguid)
did you have a failure with this? in what environment? On 5/6/16, Moriyoshi Koizumi wrote: > From: Moriyoshi koizumi > > Signed-off-by: Moriyoshi koizumi > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index 1f684d2..fb8d7d3 100755 > --- a/configure > +++ b/configure > @@ -2832,7 +2832,7 @@ decklink_indev_extralibs="-lstdc++" > decklink_outdev_deps="decklink pthreads" > decklink_outdev_extralibs="-lstdc++" > dshow_indev_deps="IBaseFilter" > -dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 > -lshlwapi" > +dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 > -lshlwapi -ldxguid" > dv1394_indev_deps="dv1394" > dv1394_indev_select="dv_demuxer" > fbdev_indev_deps="linux_fb_h" > -- > 2.8.0 > > ___ > 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] Cyrillic devices name support in libavdevice/dshow
Perhaps somebody could give me a registry .reg file that has some Cyrillic characters in a name so I can attempt to repro the problem? On 12/16/15, Ivan Uskov wrote: > Hello All, > > Wednesday, December 16, 2015, 11:36:17 PM, you wrote: > > IU> Hello Derek, > > IU> Wednesday, December 16, 2015, 8:24:33 PM, you wrote: > > DB>> On 12/16/2015 4:29 PM, Roger Pack wrote: >>>> Still mulling over why this would be needed...hm > > DB>> It makes sense that CP_OEMCP is needed for device names, in my mind, > DB>> after reading https://support.microsoft.com/en-us/kb/108450 - however, > DB>> I don't think changing the generic functions in cmdutils.c is correct > DB>> here. > IU> The actual implementation of these functions for Windows platform looks > buggy. > IU> Are will work right only for ASCII characters subset. > IU> It is hard to imagine what the reason was to use CP_UTF8 in > windows-related code. > IU> Windows never use UTF8 in command line and in other places here only > 8 bit > IU> OEM code pages or 16 bit unicode are possible. > IU> So using CP_OEMCP looks much more appropriate and correct. > > IU> But suggested patch looks incomplete, it is quite strange when > dup_wchar_to_utf8() > IU> function internally performs an action which does not match > with the > IU> function name. :-) > IU> So dup_wchar_to_utf8() should be also renamed to dup_wchar_to_oem() for > example. > After some more deep thinking I should to take all my words back. :-) > Using OEMCP in suggested patch will break uncode files processing. So it is > necessary to > resolve the issue from an opposite end: it is necessary to convert device > name to > UTF8 and do no touch existing functions. > > > > -- > Best regards, > Ivanmailto:ivan.us...@nablet.com > > ___ > 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] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress
On 12/29/15, Hendrik Leppkes wrote: > On Wed, Dec 30, 2015 at 12:33 AM, Hendrik Leppkes > wrote: >> On Wed, Dec 30, 2015 at 12:23 AM, Roger Pack >> wrote: >>>> OK I had this great idea to capture the incoming MPEG2 transport >>>> stream from the digital TV capture device. Kind of like "raw" stream, >>>> so FFmpeg could have access to, for instance, all the audio stream. >>>> >>>> It appears that the type coming out of the tuner is: >>>> MEDIATYPE_Stream >>>> with subtype >>>> KSDATAFORMAT_SUBTYPE_BDA_MPEG2_TRANSPORT >>>> which is apparently treated the same as MEDIASUBTYPE_MPEG2_TRANSPORT >>>> by the built in directshow mpeg demuxer [1] so I assume is some kind >>>> of typical MPEG2 TS stream. >>>> >>>> I had hoped that if I set dshow's AVStream's codec_id to >>>> codec->codec_id = AV_CODEC_ID_NONE; >>>> codec->codec_type = AVMEDIA_TYPE_DATA; >>> >>> Oops that was meant to be >>> >>> codec->codec_id = AV_CODEC_ID_MPEG2TS; >>> codec->codec_type = AVMEDIA_TYPE_DATA; >>> >>>> That it would somehow recognize that I was sending it an MPEG stream >>>> and insert an appropriate demuxer for me. >>>> >>>> However, when I run it, it fails like this: >>>> >>>> Input #0, dshow, from 'video=Hauppauge WinTV 885 BDA Tuner/Demod': >>>> Duration: N/A, bitrate: N/A >>>> Codec 0x2 is not in the full list. >>>> Stream #0:0, 0, 1/2700: Data: unknown_codec, 0/1 >>>> Successfully opened the file. >>>> Output #0, mp4, to 'yo.mp4': >>>> Output file #0 does not contain any stream >>>> >>>> so it's definitely not, for instance, doing a probe or analyze on the >>>> MPEG stream >>>> >>>> Is this possible or any hints/tips/tricks I could possibly use? >>> >>> To answer my own question, I turned the dshow capture device into both >>> an AVInputFormat *and* a URLProtocol that "wraps" the AVInputFormat. >>> Apparently ffmpeg can receive "raw" bytes only from URLProtocol (?) >>> This way worked great both "segmented" MPEG2VIDEO streams as well as >>> "raw" MPEG TS streams. >>> >> >> You should probably just make it use the mpegts demuxer directly, say >> like the rtsp demuxer. >> We have an API for that in the form of avpriv_mpegts_parse_packet >> >> Making an input device a protocol seems rather ugly, the user needs to >> know beforehand how to call it that way. True, I wish I didn't have to do it (ex: use AV_CODEC_ID_MPEG2TS and it "just work" -- any hints or clues to that welcome!) I'd like to give them access to the command line demultiplexing options that raw MPEG streams currently have. (ex: if they want 3 streams out of 10, like https://trac.ffmpeg.org/wiki/Map#Example8) without having to build that functionality into dshow parameters as well. > Or as an alternative, why not just add the mpegts demuxer to the DShow > graph as well and directly get video/audio streams. > For Live TV functionality, the MS demuxer seems to be working quite well. Mostly so that they can record a channel and its sibling sub channels (from the same card) all at once, which can be convenient at times. Cheers! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] dshow: Make dshow device buildable on Cygwin
which compiler (mingw-w64 I presume?) are you using here?
On 5/6/16, Moriyoshi Koizumi wrote:
> From: Moriyoshi koizumi
>
> wchar_t is not always the same thing as WCHAR.
>
> Signed-off-by: Moriyoshi koizumi
> ---
> libavdevice/dshow.c | 6 +++---
> libavdevice/dshow_capture.h | 10 +-
> libavdevice/dshow_filter.c | 16
> libavdevice/dshow_pin.c | 10 +-
> 4 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
> index 678861d..432b643 100644
> --- a/libavdevice/dshow.c
> +++ b/libavdevice/dshow.c
> @@ -129,7 +129,7 @@ dshow_read_close(AVFormatContext *s)
> return 0;
> }
>
> -static char *dup_wchar_to_utf8(wchar_t *w)
> +static char *dup_wchar_to_utf8(WCHAR *w)
> {
> char *s = NULL;
> int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
> @@ -599,7 +599,7 @@ dshow_cycle_pins(AVFormatContext *avctx, enum
> dshowDeviceType devtype,
> GUID category;
> DWORD r2;
> char *name_buf = NULL;
> -wchar_t *pin_id = NULL;
> +WCHAR *pin_id = NULL;
> char *pin_buf = NULL;
> char *desired_pin_name = devtype == VideoDevice ?
> ctx->video_pin_name : ctx->audio_pin_name;
>
> @@ -734,7 +734,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
> *devenum,
> IStream *ofile_stream = NULL;
> IPersistStream *pers_stream = NULL;
>
> -const wchar_t *filter_name[2] = { L"Audio capture filter", L"Video
> capture filter" };
> +const WCHAR *filter_name[2] = { L"Audio capture filter", L"Video
> capture filter" };
>
>
> if ( ((ctx->audio_filter_load_file) &&
> (strlen(ctx->audio_filter_load_file)>0) && (sourcetype ==
> AudioSourceDevice)) ||
> diff --git a/libavdevice/dshow_capture.h b/libavdevice/dshow_capture.h
> index f26eaf9..860b782 100644
> --- a/libavdevice/dshow_capture.h
> +++ b/libavdevice/dshow_capture.h
> @@ -176,7 +176,7 @@ long WINAPI libAVPin_ConnectedTo
> (libAVPin *, IPin **);
> long WINAPI libAVPin_ConnectionMediaType (libAVPin *,
> AM_MEDIA_TYPE *);
> long WINAPI libAVPin_QueryPinInfo(libAVPin *, PIN_INFO
> *);
> long WINAPI libAVPin_QueryDirection (libAVPin *,
> PIN_DIRECTION *);
> -long WINAPI libAVPin_QueryId (libAVPin *, wchar_t
> **);
> +long WINAPI libAVPin_QueryId (libAVPin *, WCHAR
> **);
> long WINAPI libAVPin_QueryAccept (libAVPin *, const
> AM_MEDIA_TYPE *);
> long WINAPI libAVPin_EnumMediaTypes (libAVPin *,
> IEnumMediaTypes **);
> long WINAPI libAVPin_QueryInternalConnections(libAVPin *, IPin **,
> unsigned long *);
> @@ -249,7 +249,7 @@ libAVEnumMediaTypes *libAVEnumMediaTypes_Create(const
> AM_MEDIA_TYPE *type);
> struct libAVFilter {
> IBaseFilterVtbl *vtbl;
> long ref;
> -const wchar_t *name;
> +const WCHAR *name;
> libAVPin *pin;
> FILTER_INFO info;
> FILTER_STATE state;
> @@ -272,10 +272,10 @@ long WINAPI libAVFilter_GetState
> (libAVFilter *, DWORD, FILTER_ST
> long WINAPI libAVFilter_SetSyncSource (libAVFilter *,
> IReferenceClock *);
> long WINAPI libAVFilter_GetSyncSource (libAVFilter *,
> IReferenceClock **);
> long WINAPI libAVFilter_EnumPins (libAVFilter *, IEnumPins
> **);
> -long WINAPI libAVFilter_FindPin(libAVFilter *, const
> wchar_t *, IPin **);
> +long WINAPI libAVFilter_FindPin(libAVFilter *, const WCHAR
> *, IPin **);
> long WINAPI libAVFilter_QueryFilterInfo(libAVFilter *, FILTER_INFO
> *);
> -long WINAPI libAVFilter_JoinFilterGraph(libAVFilter *,
> IFilterGraph *, const wchar_t *);
> -long WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, wchar_t
> **);
> +long WINAPI libAVFilter_JoinFilterGraph(libAVFilter *,
> IFilterGraph *, const WCHAR *);
> +long WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, WCHAR **);
>
> void libAVFilter_Destroy(libAVFilter *);
> libAVFilter *libAVFilter_Create (void *, void *, enum
> dshowDeviceType);
> diff --git a/libavdevice/dshow_filter.c b/libavdevice/dshow_filter.c
> index 7360adc..3ba3871 100644
> --- a/libavdevice/dshow_filter.c
> +++ b/libavdevice/dshow_filter.c
> @@ -20,6 +20,8 @@
> */
>
> #include "dshow_capture.h"
> +#include
> +#include
>
> DECLARE_QUERYINTERFACE(libAVFilter,
> { {&IID_IUnknown,0}, {&IID_IBaseFilter,0} })
> @@ -108,14 +110,14 @@ libAVFilter_EnumPins(libAVFilter *this, IEnumPins
> **enumpin)
> return S_OK;
> }
> long WINAPI
> -libAVFilter_FindPin(libAVFilter *this, const wchar_t *id, IPin **pin)
> +libAVFilter_FindPin(libAVFilter *this, const WCHAR *id, IPin **pin)
> {
> libAVPin *found = NULL;
> dshowdebug("libAVFilter_FindPin(%p)\n", this);
>
> if (!id || !pin)
> return E_POINTER;
> -if (!wcscmp(id, L"In")) {
> +
[FFmpeg-devel] PATCH: dshow: don't add two instances of same device to graphs
A handful of devices don't support this, and the rest work fine with it :)
-roger-
From e724d7f169bcae3217455cd88f9c023d275d367a Mon Sep 17 00:00:00 2001
From: rogerdpack
Date: Wed, 15 Jun 2016 02:17:11 -0600
Subject: [PATCH] dshow: don't add two instances of same device to graphs
Signed-off-by: rogerdpack
---
libavdevice/dshow.c | 37 ++---
libavdevice/dshow_capture.h | 2 ++
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 5f2cad7..e1ac855 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -108,6 +108,10 @@ dshow_read_close(AVFormatContext *s)
av_freep(&ctx->device_name[0]);
if (ctx->device_name[1])
av_freep(&ctx->device_name[1]);
+if (ctx->device_unique_name[0])
+av_freep(&ctx->device_unique_name[0]);
+if (ctx->device_unique_name[1])
+av_freep(&ctx->device_unique_name[1]);
if(ctx->mutex)
CloseHandle(ctx->mutex);
@@ -205,7 +209,8 @@ fail:
*/
static int
dshow_cycle_devices(AVFormatContext *avctx, ICreateDevEnum *devenum,
-enum dshowDeviceType devtype, enum dshowSourceFilterType
sourcetype, IBaseFilter **pfilter)
+enum dshowDeviceType devtype, enum dshowSourceFilterType
sourcetype,
+IBaseFilter **pfilter, char **device_unique_name)
{
struct dshow_ctx *ctx = avctx->priv_data;
IBaseFilter *device_filter = NULL;
@@ -276,10 +281,13 @@ dshow_cycle_devices(AVFormatContext *avctx,
ICreateDevEnum *devenum,
av_log(avctx, AV_LOG_ERROR, "Unable to BindToObject for
%s\n", device_name);
goto fail1;
}
+*device_unique_name = unique_name;
+// success, loop will end now
}
} else {
av_log(avctx, AV_LOG_INFO, " \"%s\"\n", friendly_name);
av_log(avctx, AV_LOG_INFO, "Alternative name \"%s\"\n",
unique_name);
+av_free(unique_name);
}
fail1:
@@ -288,7 +296,6 @@ fail1:
if (bind_ctx)
IBindCtx_Release(bind_ctx);
av_free(friendly_name);
-av_free(unique_name);
if (bag)
IPropertyBag_Release(bag);
IMoniker_Release(m);
@@ -706,14 +713,15 @@ dshow_list_device_options(AVFormatContext *avctx,
ICreateDevEnum *devenum,
{
struct dshow_ctx *ctx = avctx->priv_data;
IBaseFilter *device_filter = NULL;
+char *device_unique_name = NULL;
int r;
-if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype,
&device_filter)) < 0)
+if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype,
&device_filter, &device_unique_name)) < 0)
return r;
ctx->device_filter[devtype] = device_filter;
if ((r = dshow_cycle_pins(avctx, devtype, sourcetype, device_filter,
NULL)) < 0)
return r;
-
+av_freep(&device_unique_name);
return 0;
}
@@ -723,6 +731,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
*devenum,
{
struct dshow_ctx *ctx = avctx->priv_data;
IBaseFilter *device_filter = NULL;
+char *device_filter_unique_name = NULL;
IGraphBuilder *graph = ctx->graph;
IPin *device_pin = NULL;
libAVPin *capture_pin = NULL;
@@ -733,6 +742,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
*devenum,
IStream *ifile_stream = NULL;
IStream *ofile_stream = NULL;
IPersistStream *pers_stream = NULL;
+enum dshowDeviceType otherDevType = (devtype == VideoDevice) ? AudioDevice
: VideoDevice;
const wchar_t *filter_name[2] = { L"Audio capture filter", L"Video capture
filter" };
@@ -766,13 +776,26 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
*devenum,
av_log(avctx, AV_LOG_INFO, "Capture filter loaded successfully from
file \"%s\".\n", filename);
} else {
-if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype,
&device_filter)) < 0) {
+if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype,
&device_filter, &device_filter_unique_name)) < 0) {
ret = r;
goto error;
}
}
+ if (ctx->device_filter[otherDevType]) {
+// avoid adding add two instances of the same device to the graph, one
for video, one for audio
+// a few devices don't support this (could also do this check earlier
to avoid double crossbars, etc. but they seem OK)
+if (strcmp(device_filter_unique_name,
ctx->device_unique_name[otherDevType]) == 0) {
+ av_log(avctx, AV_LOG_DEBUG, "reusing previous graph capture
filter... %s\n", device_filter_unique_name);
+ IBaseFilter_Release(device_filter);
+ device_filter = ctx->device_filter[otherDevType];
+ IBaseFilter_AddRef(ctx->device_filter[otherDevType]);
+} else {
+av_log(avctx, AV_LOG_DEBUG, "not reusing previous graph capture
filter %
Re: [FFmpeg-devel] PATCH: dshow: don't add two instances of same device to graphs
On 6/15/16, Clément Bœsch wrote: > On Wed, Jun 15, 2016 at 02:54:09AM -0600, Roger Pack wrote: >> A handful of devices don't support this, and the rest work fine with it >> :) >> >> -roger- > >> From e724d7f169bcae3217455cd88f9c023d275d367a Mon Sep 17 00:00:00 2001 >> From: rogerdpack >> Date: Wed, 15 Jun 2016 02:17:11 -0600 >> Subject: [PATCH] dshow: don't add two instances of same device to graphs >> >> Signed-off-by: rogerdpack >> --- >> libavdevice/dshow.c | 37 ++--- >> libavdevice/dshow_capture.h | 2 ++ >> 2 files changed, 32 insertions(+), 7 deletions(-) >> >> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c >> index 5f2cad7..e1ac855 100644 >> --- a/libavdevice/dshow.c >> +++ b/libavdevice/dshow.c >> @@ -108,6 +108,10 @@ dshow_read_close(AVFormatContext *s) >> av_freep(&ctx->device_name[0]); >> if (ctx->device_name[1]) >> av_freep(&ctx->device_name[1]); > >> +if (ctx->device_unique_name[0]) >> +av_freep(&ctx->device_unique_name[0]); >> +if (ctx->device_unique_name[1]) >> +av_freep(&ctx->device_unique_name[1]); > > I can't comment the rest of the patch, but please remove the ifs. They are, > and always were, totally useless. Just like those above. OK see also attached patch, to be applied after patch 1. Thanks, will wait three days and if no objections, request these patches be committed. Cheers! From 61e07cc85785345122832b1b5333412b5272c545 Mon Sep 17 00:00:00 2001 From: rogerdpack Date: Fri, 17 Jun 2016 14:04:34 -0600 Subject: [PATCH 2/2] dshow: avoid duplicate NULL check before free Signed-off-by: rogerdpack --- libavdevice/dshow.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c index e1ac855..127e4c2 100644 --- a/libavdevice/dshow.c +++ b/libavdevice/dshow.c @@ -104,14 +104,10 @@ dshow_read_close(AVFormatContext *s) if (ctx->device_filter[AudioDevice]) IBaseFilter_Release(ctx->device_filter[AudioDevice]); -if (ctx->device_name[0]) -av_freep(&ctx->device_name[0]); -if (ctx->device_name[1]) -av_freep(&ctx->device_name[1]); -if (ctx->device_unique_name[0]) -av_freep(&ctx->device_unique_name[0]); -if (ctx->device_unique_name[1]) -av_freep(&ctx->device_unique_name[1]); +av_freep(&ctx->device_name[0]); +av_freep(&ctx->device_name[1]); +av_freep(&ctx->device_unique_name[0]); +av_freep(&ctx->device_unique_name[1]); if(ctx->mutex) CloseHandle(ctx->mutex); -- 2.8.3.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: dshow: don't add two instances of same device to graphs
On 6/17/16, Roger Pack wrote:
> On 6/15/16, Clément Bœsch wrote:
>> On Wed, Jun 15, 2016 at 02:54:09AM -0600, Roger Pack wrote:
>>> A handful of devices don't support this, and the rest work fine with it
>>> :)
>>>
>>> -roger-
>>
>>> From e724d7f169bcae3217455cd88f9c023d275d367a Mon Sep 17 00:00:00 2001
>>> From: rogerdpack
>>> Date: Wed, 15 Jun 2016 02:17:11 -0600
>>> Subject: [PATCH] dshow: don't add two instances of same device to graphs
>>>
>>> Signed-off-by: rogerdpack
>>> ---
>>> libavdevice/dshow.c | 37 ++---
>>> libavdevice/dshow_capture.h | 2 ++
>>> 2 files changed, 32 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
>>> index 5f2cad7..e1ac855 100644
>>> --- a/libavdevice/dshow.c
>>> +++ b/libavdevice/dshow.c
>>> @@ -108,6 +108,10 @@ dshow_read_close(AVFormatContext *s)
>>> av_freep(&ctx->device_name[0]);
>>> if (ctx->device_name[1])
>>> av_freep(&ctx->device_name[1]);
>>
>>> +if (ctx->device_unique_name[0])
>>> +av_freep(&ctx->device_unique_name[0]);
>>> +if (ctx->device_unique_name[1])
>>> +av_freep(&ctx->device_unique_name[1]);
>>
>> I can't comment the rest of the patch, but please remove the ifs. They
>> are,
>> and always were, totally useless. Just like those above.
>
> OK see also attached patch, to be applied after patch 1.
> Thanks, will wait three days and if no objections, request these
> patches be committed.
OK would some kind soul please commit these for me?
Thanks!
-roger-
From e724d7f169bcae3217455cd88f9c023d275d367a Mon Sep 17 00:00:00 2001
From: rogerdpack
Date: Wed, 15 Jun 2016 02:17:11 -0600
Subject: [PATCH 1/2] dshow: don't add two instances of same device to graphs
Signed-off-by: rogerdpack
---
libavdevice/dshow.c | 37 ++---
libavdevice/dshow_capture.h | 2 ++
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 5f2cad7..e1ac855 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -108,6 +108,10 @@ dshow_read_close(AVFormatContext *s)
av_freep(&ctx->device_name[0]);
if (ctx->device_name[1])
av_freep(&ctx->device_name[1]);
+if (ctx->device_unique_name[0])
+av_freep(&ctx->device_unique_name[0]);
+if (ctx->device_unique_name[1])
+av_freep(&ctx->device_unique_name[1]);
if(ctx->mutex)
CloseHandle(ctx->mutex);
@@ -205,7 +209,8 @@ fail:
*/
static int
dshow_cycle_devices(AVFormatContext *avctx, ICreateDevEnum *devenum,
-enum dshowDeviceType devtype, enum dshowSourceFilterType
sourcetype, IBaseFilter **pfilter)
+enum dshowDeviceType devtype, enum dshowSourceFilterType
sourcetype,
+IBaseFilter **pfilter, char **device_unique_name)
{
struct dshow_ctx *ctx = avctx->priv_data;
IBaseFilter *device_filter = NULL;
@@ -276,10 +281,13 @@ dshow_cycle_devices(AVFormatContext *avctx,
ICreateDevEnum *devenum,
av_log(avctx, AV_LOG_ERROR, "Unable to BindToObject for
%s\n", device_name);
goto fail1;
}
+*device_unique_name = unique_name;
+// success, loop will end now
}
} else {
av_log(avctx, AV_LOG_INFO, " \"%s\"\n", friendly_name);
av_log(avctx, AV_LOG_INFO, "Alternative name \"%s\"\n",
unique_name);
+av_free(unique_name);
}
fail1:
@@ -288,7 +296,6 @@ fail1:
if (bind_ctx)
IBindCtx_Release(bind_ctx);
av_free(friendly_name);
-av_free(unique_name);
if (bag)
IPropertyBag_Release(bag);
IMoniker_Release(m);
@@ -706,14 +713,15 @@ dshow_list_device_options(AVFormatContext *avctx,
ICreateDevEnum *devenum,
{
struct dshow_ctx *ctx = avctx->priv_data;
IBaseFilter *device_filter = NULL;
+char *device_unique_name = NULL;
int r;
-if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype,
&device_filter)) < 0)
+if ((r = dshow_cycle_devices(avctx, devenum, devtype, sourcetype,
&device_filter, &device_unique_name)) < 0)
return r;
ctx->device_filter[devtype] = device_filter;
if ((r = dshow_cycle_pins(avctx, devtype, sourcetype, device_filter,
NULL)) < 0)
return r;
-
+av_freep(&device_unique_name);
return 0;
}
@@ -723,6 +731,7 @@ d
Re: [FFmpeg-devel] Mix image sequence to video & dshow to audio
On 6/23/16, Gábor Alsecz wrote: > Dear All, > > I am on a Windows machine and have no idea how can i: > - Grab input sound from attached mic (usb) without dshow device > OR > - mix up the following command with dshow to get audio input from attached > mic. > > ffmpeg -loop 1 -i 2K_1.jpg -vcodec libx264 -preset medium -maxrate 3000k > -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 128k -ac 2 -ar 44100 > output.mp4 > > > Any idea? you just use two "-i" so like ... -i 2K_1.jpg -f dshow -i audio="Microphone" ... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] lavd/decklink_common: Fix error caused by -Werror=missing-prototypes
could you post a copy of the compile failure for reference? On 6/26/16, Rick Kern wrote: > decklink_common.cpp includes a .cpp file from the DeckLink API which fails > to build because there are non-static functions in the included .cpp file. > This disables the missing-prototypes error so the file can be included. > > Signed-off-by: Rick Kern > --- > libavdevice/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavdevice/Makefile b/libavdevice/Makefile > index 585827b..e281825 100644 > --- a/libavdevice/Makefile > +++ b/libavdevice/Makefile > @@ -19,6 +19,8 @@ OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o > OBJS-$(CONFIG_CACA_OUTDEV) += caca.o > OBJS-$(CONFIG_DECKLINK_OUTDEV) += decklink_enc.o decklink_enc_c.o > decklink_common.o > OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o decklink_dec_c.o > decklink_common.o > +$(SUBDIR)decklink_common.o: CXXFLAGS += -Wno-error=missing-prototypes > + > OBJS-$(CONFIG_DSHOW_INDEV) += dshow_crossbar.o dshow.o > dshow_enummediatypes.o \ > dshow_enumpins.o dshow_filter.o > \ > dshow_pin.o dshow_common.o > -- > 2.9.0 > > ___ > 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 1/2] avcodec/cuvid: add cuvid decoder
OK where do we find the "Nvidia CUVID decoder" library, is it this? https://1f0.de/lav-cuvid/ On 6/10/16, Timo Rothenpieler wrote: > --- > Changelog | 2 + > MAINTAINERS| 1 + > configure | 34 +++ > libavcodec/Makefile| 5 + > libavcodec/allcodecs.c | 10 + > libavcodec/cuvid.c | 698 > + > libavcodec/version.h | 2 +- > 7 files changed, 751 insertions(+), 1 deletion(-) > create mode 100644 libavcodec/cuvid.c > > diff --git a/Changelog b/Changelog > index 3d4997f..d44f607 100644 > --- a/Changelog > +++ b/Changelog > @@ -40,6 +40,8 @@ version : > - MagicYUV decoder > - OpenExr improvements (tile data and B44/B44A support) > - BitJazz SheerVideo decoder > +- CUDA CUVID H264/HEVC decoder > + > > version 3.0: > - Common Encryption (CENC) MP4 encoding and decoding support > diff --git a/MAINTAINERS b/MAINTAINERS > index 23c0bab..4fe999d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -163,6 +163,7 @@ Codecs: >cpia.cStephan Hilb >crystalhd.c Philip Langdale >cscd.cReimar Doeffinger > + cuvid.c Timo Rothenpieler >dca.c Kostya Shishkov, Benjamin Larsson >dirac*Rostislav Pehlivanov >dnxhd*Baptiste Coudurier > diff --git a/configure b/configure > index 7c463a5..a220fa1 100755 > --- a/configure > +++ b/configure > @@ -158,6 +158,7 @@ Hardware accelerators: > > Hardware-accelerated decoding/encoding: >--enable-cudaenable dynamically linked CUDA [no] > + --enable-cuvid enable CUVID support [autodetect] >--enable-libmfx enable HW acceleration through libmfx >--enable-mmalenable decoding via MMAL [no] >--enable-nvenc enable NVIDIA NVENC support [no] > @@ -1567,6 +1568,7 @@ FEATURE_LIST=" > > HW_CODECS_LIST=" > cuda > +cuvid > libmfx > mmal > nvenc > @@ -2522,6 +2524,7 @@ audiotoolbox_extralibs="-framework CoreFoundation > -framework AudioToolbox -frame > > # hardware accelerators > crystalhd_deps="libcrystalhd_libcrystalhd_if_h" > +cuvid_deps="cuda" > d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext" > dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode" > vaapi_deps="va_va_h" > @@ -2539,6 +2542,7 @@ h263_vaapi_hwaccel_select="h263_decoder" > h263_videotoolbox_hwaccel_deps="videotoolbox" > h263_videotoolbox_hwaccel_select="h263_decoder" > h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser" > +h264_cuvid_hwaccel_deps="cuda cuvid CUVIDH264PICPARAMS" > h264_d3d11va_hwaccel_deps="d3d11va" > h264_d3d11va_hwaccel_select="h264_decoder" > h264_dxva2_hwaccel_deps="dxva2" > @@ -2564,6 +2568,7 @@ h264_vdpau_hwaccel_deps="vdpau" > h264_vdpau_hwaccel_select="h264_decoder" > h264_videotoolbox_hwaccel_deps="videotoolbox" > h264_videotoolbox_hwaccel_select="h264_decoder" > +hevc_cuvid_hwaccel_deps="cuda cuvid CUVIDHEVCPICPARAMS" > hevc_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_HEVC" > hevc_d3d11va_hwaccel_select="hevc_decoder" > hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC" > @@ -2618,6 +2623,7 @@ mpeg4_videotoolbox_hwaccel_deps="videotoolbox" > mpeg4_videotoolbox_hwaccel_select="mpeg4_decoder" > msmpeg4_crystalhd_decoder_select="crystalhd" > vc1_crystalhd_decoder_select="crystalhd" > +vc1_cuvid_hwaccel_deps="cuda cuvid CUVIDVC1PICPARAMS" > vc1_d3d11va_hwaccel_deps="d3d11va" > vc1_d3d11va_hwaccel_select="vc1_decoder" > vc1_dxva2_hwaccel_deps="dxva2" > @@ -2633,6 +2639,8 @@ vc1_vdpau_decoder_deps="vdpau" > vc1_vdpau_decoder_select="vc1_decoder" > vc1_vdpau_hwaccel_deps="vdpau" > vc1_vdpau_hwaccel_select="vc1_decoder" > +vp8_cuvid_hwaccel_deps="cuda cuvid CUVIDVP9PICPARAMS" > +vp9_cuvid_hwaccel_deps="cuda cuvid CUVIDVP9PICPARAMS" > vp9_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_VP9" > vp9_d3d11va_hwaccel_select="vp9_decoder" > vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9" > @@ -2657,6 +2665,8 @@ hwupload_cuda_filter_deps="cuda" > scale_npp_filter_deps="cuda libnpp" > > nvenc_encoder_deps="nvenc" > +h264_cuvid_decoder_deps="cuda cuvid CUVIDH264PICPARAMS" > +h264_cuvid_decoder_select="h264_mp4toannexb_bsf h264_cuvid_hwaccel" > h264_qsv_decoder_deps="libmfx" > h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec > h264_qsv_hwaccel" > h264_qsv_encoder_deps="libmfx" > @@ -2664,6 +2674,8 @@ h264_qsv_encoder_select="qsvenc" > h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264" > h264_vaapi_encoder_select="vaapi_encode golomb" > > +hevc_cuvid_decoder_deps="cuda cuvid CUVIDHEVCPICPARAMS" > +hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf hevc_cuvid_hwaccel" > hevc_qsv_decoder_deps="libmfx" > hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec > hevc_qsv_hwaccel" > hevc_qsv_enco
Re: [FFmpeg-devel] A patch for gdigrab function
OK I was able to reproduce the problem.
Patch looks good, see attached, FWIW.
Thanks!
-roger-
On Sat, Aug 16, 2014 at 4:17 PM, Michael Niedermayer
wrote:
> On Fri, Aug 08, 2014 at 05:08:46PM +0800, hlszl1...@163.com wrote:
> > hi, all
> >
> > I'm using gdigrab feature on windows, and found that the count of gdi
> objects owned by ffmpeg.exe increasing endlessly...
> >
> > Here is the patch, can someone commit it?
> > --
> > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
> > index bccfef2..e2bed14 100644
> > --- a/libavdevice/gdigrab.c
> > +++ b/libavdevice/gdigrab.c
> > @@ -451,6 +451,10 @@ static void paint_mouse_pointer(AVFormatContext
> *s1, struct gdigrab *gdigrab)
> > icon = CopyCursor(LoadCursor(NULL, IDC_ARROW));
> > }
> >
> > + /*Remarks
> > + *GetIconInfo creates bitmaps for the hbmMask and hbmColor members of
> ICONINFO.
> > + *The calling application must manage these bitmaps and delete them
> when they are no longer necessary.
> > + */
> > if (!GetIconInfo(icon, &info)) {
> > CURSOR_ERROR("Could not get icon info");
> > goto icon_error;
> > @@ -481,6 +485,10 @@ static void paint_mouse_pointer(AVFormatContext
> *s1, struct gdigrab *gdigrab)
> > }
> >
> > icon_error:
> > + if (info.hbmMask)
> > + DeleteObject(info.hbmMask);
> > + if(info.hbmColor)
> > + DeleteObject(info.hbmColor);
> > if (icon)
> > DestroyCursor(icon);
> > } else {
>
> the patch has been mangled, probably by your mail user agent
>
> also CC-ing maintainer
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Old school: Use the lowest level language in which you can solve the
> problem
> conveniently.
> New school: Use the highest level language in which the latest
> supercomputer
> can solve the problem without the user falling asleep waiting.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
0001-gdigrab-fix-gdi-object-leak-if-using-mouse-based-on-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
Do you have some instructions on how to get the headers to make this download work? Any links to some device to exercise the code, like on amazon [cheaper better LOL]. On Tue, Sep 2, 2014 at 3:26 AM, Deti Fliegl wrote: > On 30.08.14 01:22, Michael Niedermayer wrote: > >> moving code from (like from decklink_enc.cpp to decklink_common.cpp) >> should be in a seperate patch >> > Done. Both patches are attached to this mail. > > > If you want to maintain this code, please add yourself to the >> MAINTAINERs file >> > Added. > > > non static functions should have a ff_ prefix (or av if they are >> public but that isnt) >> > Done, except for CreateDeckLinkIteratorInstance which is a function that > is part of the DeckLink Mac OS X & Linux API and which is not available > under Windows. So it has to be recoded to enable code sharing between Mac > OS X, Linux and Windows. > > > also i dont really know windows & decklink stuff, so iam not the >> ideal one to review ... >> > Well basically it all should be the same. It compiles and works under > Windows too, but most people would use the direct show input support of > ffmpeg for capturing from a DeckLink device. > > Deti > > ___ > 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] Add input support for DeckLink devices.
So you tested this in linux and windows? And it works? What is the advantage of this over dshow, does it work "better" somehow [I know dshow is deficient in multiple ways, FWIW]. Or was it just to add linux support? Cheers! -roger- On Mon, Aug 18, 2014 at 12:40 PM, Deti Fliegl wrote: > Rebased commits to have all changes in one patch. Hopefully it's > complete now. > > Deti > > On 18.08.14 19:48, Deti Fliegl wrote: > > On 18.08.14 19:23, Carl Eugen Hoyos wrote: > >> Deti Fliegl fliegl.de> writes: > >> > >>> +/* free() is needed for a string returned by the DeckLink SDL. */ > >>> +#undef free > >> > >> I believe this is not needed anymore but ... > > removed it - but this has been part of the existing code which I simply > > moved to a new file. > > > >> > >>> +free((void *) tmpDisplayName); > >> > >> ... please move the comment here. > > Done. > > > >> Is the cast necessary? > > Yes. > > > >> > >>> +av_log(NULL, AV_LOG_ERROR, > >> > >> Context should not be NULL. > > Can hardly be done in this file unless you supply avctx as argument in > > every function only for av_log purposes. > > > >> > >>> +av_log(NULL, AV_LOG_INFO, "Found Decklink mode %d x > >>> %d with rate %.2f%s\n", bmd_width, bmd_height, > >>> (float)bmd_tb_den/(float)bmd_tb_num, > >>> (ctx->bmd_field_dominance==bmdLowerFieldFirst || > >>> ctx->bmd_field_dominance==bmdUpperFieldFirst)?"(i)":""); > >> > >> Please split this line. > > done. > > > >> Isn't your patch missing a configure check and > >> a change to Makefile? > > Must have missed some files to commit. Fixing patch attached to this > mail. > > > >> (What is the license of the decklink libraries?) > > There is no DeckLink library code in my patch. The already existing > > decklink encoder support covers how to build ffmpeg with the DeckLink > SDK. > > > > Deti > > > > > > > > ___ > > 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 > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
On Mon, Sep 15, 2014 at 11:19 AM, Amnon Israely wrote: > It's work already more than 24h > > Maybe it's not a big problem but in some scenario may do some problem > > Input #0, decklink, from 'DeckLink SDI (3)@3': > Duration: N/A, start: 0.00, bitrate: 172032 kb/s > Stream #0:0: Audio: pcm_s16le, 48000 Hz, 8 channels, s16, 6144 kb/s > Stream #0:1: Video: rawvideo (UYVY / 0x59565955), uyvy422, 720x576, > 165888 kb/s, 25 tbr, 1000k tbn, 25 tbc > > Audio stream map to 0:0 > > What do you think might be the problem here? > 2014-09-14 17:33 GMT+03:00 Amnon Israely : > > > I can help with testing under Linux. > > We use many deckling devices in production. > > > > 2014-09-14 17:15 GMT+03:00 Dave Rice : > > > >> > >> On Sep 14, 2014, at 7:07 AM, Deti Fliegl wrote: > >> > >> > I really would like to bring things forward, but currently nobody > wants > >> to review this patch. It's primarily something that is used under Linux > and > >> not Windows. So please would anyone have a look at my patch. > >> > >> I have a few decklink devices and would be happy to review this on Mac. > >> Does it work on Mac? > >> Dave Rice > >> > >> > Deti > >> > > >> > On 30.08.14 01:22, Michael Niedermayer wrote: > >> >> On Sat, Aug 23, 2014 at 10:50:37PM +0200, Deti Fliegl wrote: > >> >>> On 19.08.14 15:43, Carl Eugen Hoyos wrote: > >> Deti Fliegl fliegl.de> writes: > >> > >> > Minor update to propagate field dominance. > >> > >> At least a Changelog entry and a libavdevice version > >> bump are still missing, but consider waiting for a > >> real review. > >> >>> Well in the meantime I updated my patch once again to add proper > >> >>> frame sizes and frame rates to the video codec. Maybe somebody wants > >> >>> to review the patch. > >> >>> > >> >>> Deti > >> >>> > >> >> > >> >>> configure |4 > >> >>> doc/indevs.texi | 54 > >> >>> libavdevice/Makefile|5 > >> >>> libavdevice/alldevices.c|2 > >> >>> libavdevice/decklink_common.cpp | 229 + > >> >>> libavdevice/decklink_common.h | 98 +++ > >> >>> libavdevice/decklink_common_c.h | 32 ++ > >> >>> libavdevice/decklink_dec.cpp| 531 > >> > >> >>> libavdevice/decklink_dec.h | 32 ++ > >> >>> libavdevice/decklink_dec_c.c| 54 > >> >>> libavdevice/decklink_enc.cpp| 196 +- > >> >> > >> >> moving code from (like from decklink_enc.cpp to decklink_common.cpp) > >> >> should be in a seperate patch > >> >> > >> >> > >> >>> libavdevice/decklink_enc.h | 11 > >> >>> libavdevice/decklink_enc_c.c|1 > >> >>> 13 files changed, 1055 insertions(+), 194 deletions(-) > >> >> > >> >> If you want to maintain this code, please add yourself to the > >> >> MAINTAINERs file > >> >> > >> >> > >> >> [...] > >> >> > >> >>> +#ifdef _WIN32 > >> >>> +char *dup_wchar_to_utf8(wchar_t *w) > >> >> > >> >> non static functions should have a ff_ prefix (or av if they are > >> >> public but that isnt) > >> >> > >> >> also i dont really know windows & decklink stuff, so iam not the > >> >> ideal one to review ... > >> >> > >> >> [...] > >> >> > >> >> > >> >> > >> >> ___ > >> >> 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 > >> > >> ___ > >> 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 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/dshow: Don't skip audio devices if no video device is present
LGTM On Mon, Jul 15, 2024 at 12:51 AM patches via ffmpeg-devel wrote: > > The search of the current DirectShow device list has been customized so > that audio devices are always found even if no video device is connected. > > Signed-off-by: Jens Frederich > --- > libavdevice/dshow.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c > index 403e56fe13..57d8e1c0af 100644 > --- a/libavdevice/dshow.c > +++ b/libavdevice/dshow.c > @@ -645,7 +645,7 @@ static int dshow_get_device_list(AVFormatContext *avctx, > AVDeviceInfoList *devic > } > > ret = dshow_cycle_devices(avctx, devenum, VideoDevice, > VideoSourceDevice, NULL, NULL, &device_list); > -if (ret < S_OK) > +if (ret < S_OK && ret != AVERROR(EIO)) > goto error; > ret = dshow_cycle_devices(avctx, devenum, AudioDevice, > AudioSourceDevice, NULL, NULL, &device_list); > > -- > 2.43.0 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] avisynth as an internal filter, any objections?
Hi all, just wondering, if I were to write a libavfilter that basically "called out" to avisynth and had it process stuff, would there be any ideological pushback, or would it possibly be accepted? Cheers! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/dshow: Don't skip audio devices if no video device is present
On Wed, Jul 17, 2024 at 1:43 AM patches wrote: > > -Original Message- > From: ffmpeg-devel On Behalf Of Roger Pack > Sent: Wednesday, July 17, 2024 3:03 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avdevice/dshow: Don't skip audio devices > if no video device is present > > > LGTM > > I also need this fix in 5.1 release branch, is this possible? Not sure how backports work, but you could make your own fork with it in it? > > > On Mon, Jul 15, 2024 at 12:51 AM patches via ffmpeg-devel > wrote: > > > > The search of the current DirectShow device list has been customized > > so that audio devices are always found even if no video device is connected. > > > > Signed-off-by: Jens Frederich > > --- > > libavdevice/dshow.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c index > > 403e56fe13..57d8e1c0af 100644 > > --- a/libavdevice/dshow.c > > +++ b/libavdevice/dshow.c > > @@ -645,7 +645,7 @@ static int dshow_get_device_list(AVFormatContext > > *avctx, AVDeviceInfoList *devic > > } > > > > ret = dshow_cycle_devices(avctx, devenum, VideoDevice, > > VideoSourceDevice, NULL, NULL, &device_list); > > -if (ret < S_OK) > > +if (ret < S_OK && ret != AVERROR(EIO)) > > goto error; > > ret = dshow_cycle_devices(avctx, devenum, AudioDevice, > > AudioSourceDevice, NULL, NULL, &device_list); > > > > -- > > 2.43.0 > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 14/17] avdevice/dshow: Cleanup also on av_log case
On Tue, Jul 2, 2024 at 1:39 PM Michael Niedermayer wrote: > > On Mon, May 27, 2024 at 01:52:26AM +0200, Michael Niedermayer wrote: > > Fixes: CID1598550 Resource leak > > > > Sponsored-by: Sovereign Tech Fund > > Signed-off-by: Michael Niedermayer > > --- > > libavdevice/dshow.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > can someone with a clue about and means to test dshow review the dshow > patches of this set ? > i dont feel comfortable to just apply some of these with no testing > and no review They seem to not have broken anything, thanks for looking into it! :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] avisynth as an internal filter, any objections?
On Thu, Jul 18, 2024 at 6:16 AM Stefan Oltmanns via ffmpeg-devel wrote: > > AviSynth (or better VapourSynth) as filter sounds great, but is it possible? > The reason why input plugins (like FFmpegSource2) in > AviSynth/VapourSynth create an index file in a first pass is to allow > frame-accurate random access to the video. Also the exact number of > frames of a clip has to be known, because I could access that property > in VapourSynth. Yeah that's a good question, wonder how vsrawsource does it... related: https://forum.videohelp.com/threads/404486-Ffmpeg-piped-as-source-to-avisynth ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Dshow Crossbar support
On Wed, Nov 19, 2014 at 3:03 PM, Zach Swena wrote: > Hi, > > Can anyone elaborate on why direct show devices that use crossbar are not > supported by FFmpeg? Also, what is keeping someone from taking the > crossbar support found in VLC and porting it to FFmpeg, assuming the said > port complied with the FFmpeg code conventions? The current work around > seems to be to use a second piece of software to t > > Only time talent and hardware (though I might have hardware for testing). I keep meaning to try and pay Ramiro Polla to do it but haven't gotten around to it yet. Patch welcome, funding welcome. -roger- > Zach > > > > > Note: If there is somewhere else this discussion should take place, please > let me know and I will move it over there. > ___ > 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] Dshow Crossbar support
On Sun, Nov 23, 2014 at 7:46 AM, Zach Swena wrote: > Do we know how much it would cost to get this done? A capture card like > the ESCAP.TV ones are pretty cheap so getting a device to test isn't hard > or expensive. As I understand it basically any capture device with > multiple analog inputs uses this feature. > Apparently it might cost 2K'ish to get this..."pay" implemented. Does FFmpeg central here have any funds that might be able to be applied here does anyone know? (we're trying to raise funds from various sources). Cheers! -roger- > > Zach > On Nov 22, 2014 11:15 AM, "Roger Pack" wrote: > > > On Wed, Nov 19, 2014 at 3:03 PM, Zach Swena > > wrote: > > > > > Hi, > > > > > > Can anyone elaborate on why direct show devices that use crossbar are > not > > > supported by FFmpeg? Also, what is keeping someone from taking the > > > crossbar support found in VLC and porting it to FFmpeg, assuming the > said > > > port complied with the FFmpeg code conventions? The current work > around > > > seems to be to use a second piece of software to t > > > > > > > > Only time talent and hardware (though I might have hardware for testing). > > I keep meaning to try and pay Ramiro Polla to do it but haven't gotten > > around to it yet. Patch welcome, funding welcome. > > -roger- > > > > > > > Zach > > > > > > > > > > > > > > > Note: If there is somewhere else this discussion should take place, > > please > > > let me know and I will move it over there. > > > ___ > > > 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 > > > ___ > 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/4] lavd: add device capabilities API
On 2/2/14, Lukasz Marek wrote: > Signed-off-by: Lukasz Marek > --- > libavdevice/avdevice.c | 191 +++ > libavdevice/avdevice.h | 238 > + > libavdevice/version.h | 2 +- > libavformat/avformat.h | 12 +++ > libavformat/version.h | 2 +- > 5 files changed, 443 insertions(+), 2 deletions(-) (Sorry, late comment, I know this was already committed). Might be nice to also add to the cmdutils.c "show_sources" method a usage of this, output to the logger. Nice to have on the command line, but also as as nice example usage. -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] how to specify, when enumerating devices, that a device has "various options"
Hello.
My basic question at hand "how to enumerate" dshow devices.
I noticed that the current AVDeviceInfo struct (used by
avdevice_list_devices and I presume by libraries that want to use
libavdevice, to enumerate devices and options) looks the following:
typedef struct AVDeviceInfo {
char *device_name; /**< device name, format
depends on device */
char *device_description;/**< human friendly name */
} AVDeviceInfo;
I'm aware you can use the new "device capabilities" api to query a
particular device for its capabilities.
My problem here is that I have devices that have various options.
For instance a single capture device may have multiple output pins.
It could also have multiple "upstream" crossbar input sources, each of
which could send to that pin. So it's like, for one device, I have
1*pins*crossbar_pin_count total number of permutations. Somehow or
other I want to be able to let users of libav that these various
parameters are available/possible.
I could create (pins*crossbar_pin_count) different devices, each
counting as a separate device. I suppose I could put it all in
*device_name -- i.e. device_name *and* its parameters, like
"audio=name=USB Audio Device:pin=Audio Out:crossbar_pin=3"
And modify dshow so that it can accept input parameters like that
(frei0r parameters style). Is that the preferred way, any
feedback/comment? Is separating by colons the best way? If I did so
(since dshow can specify multiple sources simultaneously) it would
probably end up with options like
"audio=name=USB Audio Device:pin=Audio
Out:crossbar_pin=3:video=name=Video Device:pin=Capture" does that sem
reasonable?
Modifying it to allow parameters that way might be nice anyway since I
may need something like that for dshow later.
Thanks.
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] probable dshow bug or strangeness
On 3/11/14, Don Moir wrote: > > - Original Message - > From: "Don Moir" > To: "FFmpeg development discussions and patches" > Sent: Monday, March 10, 2014 5:27 PM > Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness > > >> >> - Original Message - >> From: "Roger Pack" >> To: "FFmpeg development discussions and patches" >> >> Sent: Monday, March 10, 2014 2:58 PM >> Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness >> >> >>> On 3/7/14, Don Moir wrote: >>>> I am posting here since not quite sure and need some advice. >>>> >>>> I got word that some captures devices were not working. Everything >>>> enumerated and went thru but no display. >>>> >>>> You get packets with zero size and then no decode success. >>>> >>>> I traced this into dshow_pin.c and function libAVMemInputPin_Receive. >>>> In >>>> this function there is: >>>> >>>> buf_size = IMediaSample_GetActualDataLength(sample); >>>> >>>> In this case, buf_size is always zero. I think it is supposed to be set >>>> somewhere with IMediaSample_SetActualDataLength and could be a coding >>>> issue >>>> with driver. >>>> >>>> This apparently happens enough where I can't just blame the driver if >>>> thats >>>> where it lies. Maybe it is supposed to be set in dshow_pin.c somewhere >>>> but >>>> don't know. >>>> >>>> When this happens (buf_size == 0), the real data length appears to be >>>> returned by IMediaSample_GetSize(sample); This is supposed to be the >>>> actual >>>> buffer length and not necessarily the data length. When I change it to >>>> use >>>> IMediaSample_GetSize it works perfect. >>> >>> Are you sure it's not just re-using the previous frame's worth of data? >> >> I think I am sure about that. It plays normal if I use GetSize and nothing >> with GetActualDataLength. >> >>> Maybe you should just ignore frames with size 0? >>> Just wondering. >> >> GetActualDataLength is always zero in this case. I think yes you should >> ignore it but as a quick fix I used: >> >> buf_size = GetActualDataLength(sample); >> if (!buf_size) >>buf_size = GetSize(sample); >> >> If you completely ignore nothing will display and basically same thing. >> >> The above is not correct and something else is going on. Still looking >> into it but have to do some other things first. If you have >> any ideas let me know. > > Using above quick fix only allows for some display. It is not correct though > (display is a bit weird) and that does not overcome the > real problem which is still unknown. > > The thing about GetSize in this case is it always returns the expected frame > size. Be it RGB, YUV, etc, the size returned by GetSize > is the expected frame size. > > I have about 3 or 4 normal USB cameras and they all work correctly with > GetActualDataLength etc. Just some assortment of capture > devices are not working and this information came to me from end users. > > The problem as reported to me was: Everything list ok but you get no > display. So I had to find some software capture device that > reproduced the problem. > > I came across MediaLooks capture device and it seems to indicate the > problems reported by users. List ok but no display. > > Roger if you or anyone else wants to take a look, you can download the > MediaLooks dshow filter here. It's free (ignore buy button) > and easy. Download, Install, no BS. > > http://www.medialooks.com/screen_capture/ The latest Medialooks seem to work ok for me [windows 7] maybe they fixed a bug (I did report one to them LOL)? Do you have an older installer that repro's the problem [or, if you can repro it locally, maybe test this: http://test.freeldssheetmusic.org/music/download_file?download_id=46628&name=ffmpeg.13.exe (it's got one minor change that may be related, plus multiple other medium size changes but hopefully unrelated) the minor change is https://github.com/rdp/FFmpeg/commit/d820fa3cd5c8aac256341965ce400efdf91b5edf basically I'm just curious to see if the problem's still there, since I can't seem to repro it with Medialooks anymore, thanks to their "30 day limit" Thanks. -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] aversion to .cpp files?
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! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] dshow crossbar support PATCH es
OK I have made modifications to the dshow source so that it adds the ability to specify capture device by "more unique" name, capture pin by name, crossbar device support [this is basically any capture source with multiple inputs--definitely the most requested feature to date] and ability to use "combined" video+audio sources for both video and audio. It can be found on the github rdp/ffmpeg "dshow_crossbar" branch https://github.com/rdp/ffmpeg/tree/dshow_crossbar I'm not sure what the convention is (I was told last time to just mention a branch that could be merged?) Let me know if anything else is needed. Thanks! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] dshow crossbar support PATCH es
On 1/23/15, Michael Niedermayer wrote: > On Fri, Jan 23, 2015 at 07:06:39AM -0700, Roger Pack wrote: >> OK I have made modifications to the dshow source so that it adds the >> ability to specify capture device by "more unique" name, capture pin >> by name, crossbar device support [this is basically any capture source >> with multiple inputs--definitely the most requested feature to date] >> and ability to use "combined" video+audio sources for both video and >> audio. >> It can be found on the github rdp/ffmpeg "dshow_crossbar" branch >> https://github.com/rdp/ffmpeg/tree/dshow_crossbar >> I'm not sure what the convention is (I was told last time to just >> mention a branch that could be merged?) Let me know if anything else >> is needed. > > as you are the maintainer of the dshow code, nothing else is needed > if you want a dshow branch merged, it will be merged OK, good to know. Could you next merge the rdp/dshow_tv_tuner branch for me please? Thanks. -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] PATCH dshow show devices options
See attached. Hope I didn't get it reversed or something weird. -roger- 0001-dshow-show-incremental-values-allowed.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH dshow show devices options
On 1/30/15, Don Moir wrote: > > - Original Message - > From: "Roger Pack" > To: "FFmpeg development discussions and patches" > Sent: Friday, January 30, 2015 7:09 AM > Subject: [FFmpeg-devel] PATCH dshow show devices options > > >> See attached. Hope I didn't get it reversed or something weird. >> -roger- >> > -#define DSHOWDEBUG 0 > +/* Set to 1 to enable lots of verbose DSHOW debug info the logger */ > +#define DSHOWDEBUG 1 > > Seems to turn on a lot of over head even if not displayed. Oops good eye. Thought I had just added the comment but no. Revision attached. If you'd like to review the other recent dshow commits feedback welcome there also. Cheers! -roger- 0001-dshow-show-incremental-values-allowed.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH dshow show devices options
On 1/30/15, Michael Niedermayer wrote:
> On Fri, Jan 30, 2015 at 08:55:45AM -0700, Roger Pack wrote:
>> On 1/30/15, Don Moir wrote:
>> >
>> > - Original Message -
>> > From: "Roger Pack"
>> > To: "FFmpeg development discussions and patches"
>> >
>> > Sent: Friday, January 30, 2015 7:09 AM
>> > Subject: [FFmpeg-devel] PATCH dshow show devices options
>> >
>> >
>> >> See attached. Hope I didn't get it reversed or something weird.
>> >> -roger-
>> >>
>> > -#define DSHOWDEBUG 0
>> > +/* Set to 1 to enable lots of verbose DSHOW debug info the logger */
>> > +#define DSHOWDEBUG 1
>> >
>> > Seems to turn on a lot of over head even if not displayed.
>>
>> Oops good eye. Thought I had just added the comment but no.
>> Revision attached.
>>
>> If you'd like to review the other recent dshow commits feedback
>> welcome there also.
>> Cheers!
>> -roger-
>
>> dshow.c | 12 +++-
>> dshow_capture.h |1 +
>> 2 files changed, 8 insertions(+), 5 deletions(-)
>> 8cc6a2d1787151cc1a72be27dd5d5178784eb15a
>> 0001-dshow-show-incremental-values-allowed.patch
>> From e8e08ee49c6f80b02334891207d9f0d1b165b4b9 Mon Sep 17 00:00:00 2001
>> From: rogerdpack
>> Date: Fri, 30 Jan 2015 08:53:16 -0700
>> Subject: [PATCH] dshow: show incremental values allowed
>>
>> Signed-off-by: rogerdpack
>> ---
>> libavdevice/dshow.c | 12 +++-
>> libavdevice/dshow_capture.h | 1 +
>> 2 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
>> index d03670e..f823793 100644
>> --- a/libavdevice/dshow.c
>> +++ b/libavdevice/dshow.c
>> @@ -365,18 +365,18 @@ dshow_cycle_formats(AVFormatContext *avctx, enum
>> dshowDeviceType devtype,
>> enum AVCodecID codec_id = av_codec_get_id(tags,
>> bih->biCompression);
>> AVCodec *codec = avcodec_find_decoder(codec_id);
>> if (codec_id == AV_CODEC_ID_NONE || !codec) {
>> -av_log(avctx, AV_LOG_INFO, " unknown compression
>> type 0x%X", (int) bih->biCompression);
>> +av_log(avctx, AV_LOG_INFO, " unknown compression
>> type [please report] 0x%X", (int) bih->biCompression);
>
> this maybe should say where to report to like email address or url
> of ffmpeg-devel
>
> the other changes look fine though if one wanted to nitpick could
> be in seperate patches
Good idea, will revise and repost [I thought of some more stuff I
wanted to add anyway, so will post it all together].
Thanks.
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH dshow show devices options
On 1/31/15, Roger Pack wrote:
> On 1/30/15, Michael Niedermayer wrote:
>> On Fri, Jan 30, 2015 at 08:55:45AM -0700, Roger Pack wrote:
>>> On 1/30/15, Don Moir wrote:
>>> >
>>> > - Original Message -
>>> > From: "Roger Pack"
>>> > To: "FFmpeg development discussions and patches"
>>> >
>>> > Sent: Friday, January 30, 2015 7:09 AM
>>> > Subject: [FFmpeg-devel] PATCH dshow show devices options
>>> >
>>> >
>>> >> See attached. Hope I didn't get it reversed or something weird.
>>> >> -roger-
>>> >>
>>> > -#define DSHOWDEBUG 0
>>> > +/* Set to 1 to enable lots of verbose DSHOW debug info the logger */
>>> > +#define DSHOWDEBUG 1
>>> >
>>> > Seems to turn on a lot of over head even if not displayed.
>>>
>>> Oops good eye. Thought I had just added the comment but no.
>>> Revision attached.
>>>
>>> If you'd like to review the other recent dshow commits feedback
>>> welcome there also.
>>> Cheers!
>>> -roger-
>>
>>> dshow.c | 12 +++-
>>> dshow_capture.h |1 +
>>> 2 files changed, 8 insertions(+), 5 deletions(-)
>>> 8cc6a2d1787151cc1a72be27dd5d5178784eb15a
>>> 0001-dshow-show-incremental-values-allowed.patch
>>> From e8e08ee49c6f80b02334891207d9f0d1b165b4b9 Mon Sep 17 00:00:00 2001
>>> From: rogerdpack
>>> Date: Fri, 30 Jan 2015 08:53:16 -0700
>>> Subject: [PATCH] dshow: show incremental values allowed
>>>
>>> Signed-off-by: rogerdpack
>>> ---
>>> libavdevice/dshow.c | 12 +++-
>>> libavdevice/dshow_capture.h | 1 +
>>> 2 files changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
>>> index d03670e..f823793 100644
>>> --- a/libavdevice/dshow.c
>>> +++ b/libavdevice/dshow.c
>>> @@ -365,18 +365,18 @@ dshow_cycle_formats(AVFormatContext *avctx, enum
>>> dshowDeviceType devtype,
>>> enum AVCodecID codec_id = av_codec_get_id(tags,
>>> bih->biCompression);
>>> AVCodec *codec = avcodec_find_decoder(codec_id);
>>> if (codec_id == AV_CODEC_ID_NONE || !codec) {
>>> -av_log(avctx, AV_LOG_INFO, " unknown
>>> compression
>>> type 0x%X", (int) bih->biCompression);
>>> +av_log(avctx, AV_LOG_INFO, " unknown
>>> compression
>>> type [please report] 0x%X", (int) bih->biCompression);
>>
>> this maybe should say where to report to like email address or url
>> of ffmpeg-devel
>>
>> the other changes look fine though if one wanted to nitpick could
>> be in seperate patches
OK see the attached.
Thanks!
0001-dshow-note-where-to-report-missing-codecs-add-commen.patch
Description: Binary data
0002-dshow-show-incremental-values-allowed.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C
On 7/5/12, Michael Niedermayer wrote: > On Mon, Jun 25, 2012 at 02:21:21PM +0200, Michael Niedermayer wrote: >> On Tue, Jun 19, 2012 at 07:10:04PM +0200, Reimar Döffinger wrote: >> > On 19 Jun 2012, at 11:31, Joe Wreschnig >> > wrote: >> > > On Windows, the Ctrl+Break key combination usually does what Ctrl+C >> > > does. It is more common for processes to send other processes >> > > Ctrl+Break rather than Ctrl+C, because sending Ctrl+C / SIGINT >> > > doesn't >> > > work if you started a child in a new process group. >> > > >> > > This patch makes ffmpeg.exe register what Windows calls a console >> > > control event handler, which allows it to intercept Ctrl+Break. It >> > > hands it off directly to the usual SIGINT/SIGTERM handler. The same >> > > function also processes closing the console window, mapping it to >> > > SIGTERM. >> > > >> > > Obviously, this is only enabled if compiling for a platform where >> > > SetConsoleCtrlHandler is available (i.e. modern Windows). >> > >> > What is "modern"? Also it is rather unusual to recompile for different >> > Windows versions, couldn't you with about the same effort just use >> > GetProcAddress (more complex code, but in exchange you'd save on all the >> > configure changes and #ifs). >> >> It seems versions that dont support this are no longer supported >> by microsoft. IMHO we shouldnt bother too much with such old windows >> versions unless someone wants to / volunteers to do it. >> >> thus, if there are no objections i will apply this patch once a few >> minor issues are fixed (ifdef breaking compile to be precisse) > > iam waiting for a working patch > i could try to fix it before applying myself but with patches for > non linux platforms i prefer to avoid changing as the changes would > be untested ,.. Sorry I dropped the ball on this one. See attached. The major gains we get out of this (in my head at least) is hopefully better shutdown if somebody logs out (which has bitten me before). Or if someone closes a console window which also shuts down FFmpeg. I noticed that even with handling notifications of "logout" that ffmpeg can still easily leave behind corrupted mp4 files (it gets killed quickly after). Makes me wonder if there's some way to make it shutdown more quickly, but I'm not sure if it's a problem yet or not. Cheers! -roger- 0001-windows-respond-to-logoff-and-ctrl-break-messages.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] patch: log when hard exiting from too many signals.
If it looks worth anything, see attached (there's only one file). Thanks! 0002-log-error-message-when-shutting-down-from-too-many-s.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] verbiage
Hello again. I was thinking this text: Received signal %d: terminating. Today sounds as if the process is "hard exiting" (like SIGKILL or some odd) when it might be as benign as a ctrl+c that is used as a normal shutdown process. Perhaps it could be made to be something like: Shutting down because received signal %d To avoid confusion? (If no response I'll submit a patch with the same). Cheers! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch: log when hard exiting from too many signals.
On 6/24/15, wm4 wrote:
> On Wed, 24 Jun 2015 13:04:27 +0200
> Michael Niedermayer wrote:
>
>> On Wed, Jun 24, 2015 at 04:28:22AM -0600, Roger Pack wrote:
>> > If it looks worth anything, see attached (there's only one file).
>> > Thanks!
>>
>> > ffmpeg.c |4 +++-
>> > 1 file changed, 3 insertions(+), 1 deletion(-)
>> > 76e781dafd7324903c7cc08dbf297bd95841126c
>> > 0002-log-error-message-when-shutting-down-from-too-many-s.patch
>> > From dad4f89ec0dc5bdeaeb1923e159fa12655bdde7a Mon Sep 17 00:00:00 2001
>> > From: rogerdpack
>> > Date: Wed, 24 Jun 2015 04:26:26 -0600
>> > Subject: [PATCH 2/2] log error message when shutting down from too many
>> > signals
>> >
>> > Signed-off-by: rogerdpack
>> > ---
>> > ffmpeg.c | 4 +++-
>> > 1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/ffmpeg.c b/ffmpeg.c
>> > index 720e105..6aa5d1b 100644
>> > --- a/ffmpeg.c
>> > +++ b/ffmpeg.c
>> > @@ -324,8 +324,10 @@ sigterm_handler(int sig)
>> > received_sigterm = sig;
>> > received_nb_signals++;
>> > term_exit_sigsafe();
>> > -if(received_nb_signals > 3)
>> > +if(received_nb_signals > 3){
>>
>> > +av_log(NULL, AV_LOG_ERROR, "Received %d shutdown signals, hard
>> > exiting.", received_nb_signals);
>>
>> i think its better to use fprintf(stderr,...
>> here instead of av_log()
>>
>> when things are already stuck for some reason staying with the
>> simpler, lower level code seems more robust to me
>>
>> [...]
>>
>
> Neither av_log not printf() are safe in a signal handler.
>
> You could use write().
I'm not as familiar with write, unfortunately. Here's a printf
version FWIW, feel free to rewrite it as desired.
0002-log-error-message-when-shutting-down-from-too-many.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C
On 6/24/15, Michael Niedermayer wrote: > On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote: >> On 7/5/12, Michael Niedermayer wrote: >> > On Mon, Jun 25, 2012 at 02:21:21PM +0200, Michael Niedermayer wrote: >> >> On Tue, Jun 19, 2012 at 07:10:04PM +0200, Reimar Döffinger wrote: >> >> > On 19 Jun 2012, at 11:31, Joe Wreschnig >> >> > wrote: >> >> > > On Windows, the Ctrl+Break key combination usually does what >> >> > > Ctrl+C >> >> > > does. It is more common for processes to send other processes >> >> > > Ctrl+Break rather than Ctrl+C, because sending Ctrl+C / SIGINT >> >> > > doesn't >> >> > > work if you started a child in a new process group. >> >> > > >> >> > > This patch makes ffmpeg.exe register what Windows calls a console >> >> > > control event handler, which allows it to intercept Ctrl+Break. It >> >> > > hands it off directly to the usual SIGINT/SIGTERM handler. The >> >> > > same >> >> > > function also processes closing the console window, mapping it to >> >> > > SIGTERM. >> >> > > >> >> > > Obviously, this is only enabled if compiling for a platform where >> >> > > SetConsoleCtrlHandler is available (i.e. modern Windows). >> >> > >> >> > What is "modern"? Also it is rather unusual to recompile for >> >> > different >> >> > Windows versions, couldn't you with about the same effort just use >> >> > GetProcAddress (more complex code, but in exchange you'd save on all >> >> > the >> >> > configure changes and #ifs). >> >> >> >> It seems versions that dont support this are no longer supported >> >> by microsoft. IMHO we shouldnt bother too much with such old windows >> >> versions unless someone wants to / volunteers to do it. >> >> >> >> thus, if there are no objections i will apply this patch once a few >> >> minor issues are fixed (ifdef breaking compile to be precisse) >> > >> > iam waiting for a working patch >> > i could try to fix it before applying myself but with patches for >> > non linux platforms i prefer to avoid changing as the changes would >> > be untested ,.. >> >> Sorry I dropped the ball on this one. >> See attached. The major gains we get out of this (in my head at >> least) is hopefully better shutdown if somebody logs out (which has >> bitten me before). Or if someone closes a console window which also >> shuts down FFmpeg. >> >> I noticed that even with handling notifications of "logout" that >> ffmpeg can still easily leave behind corrupted mp4 files (it gets >> killed quickly after). > >> Makes me wonder if there's some way to make it shutdown more quickly, >> but I'm not sure if it's a problem yet or not. > > iam not sure i understand ? > does windows kill the process immedeatly after CtrlHandler() returns? > if so CtrlHandler() should wait for the main loop to exit and cleanup > finishing before it returns Thanks for the pointer, you were exactly right. Appears I can basically "Sleep" in that method and thus allow FFmpeg to cleanup (in vista+ I believe it gives a max of 5 seconds which is enough). If there's some other easy way to know the main loop has exited I could use that I suppose, but it should have the same effect. See attached revision (it now writes finalizes files appropriately for the logoff/close messages). Thanks! 0001-windows-respond-to-logoff-and-ctrl-break-messages.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] verbiage
On 6/24/15, compn wrote: > On Wed, 24 Jun 2015 04:30:10 -0600 > Roger Pack wrote: > >> Received signal %d: terminating. >> >> Today sounds as if the process is "hard exiting" (like SIGKILL or some >> odd) when it might be as benign as a ctrl+c that is used as a normal >> shutdown process. >> >> Perhaps it could be made to be something like: >> >> Shutting down because received signal %d > > ffmpeg exiting normally, received signal %d > > ? I like it. Attached is an example FWIW. -roger- 0003-modify-exit-message-when-signaled.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C
On 6/25/15, James Almer wrote:
> On 24/06/15 7:19 AM, Roger Pack wrote:
>> +#ifdef HAVE_SETCONSOLECTRLHANDLER
>> +static BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
>> +{
>> +av_log(NULL, AV_LOG_DEBUG, "\nReceived windows signal %d\n",
>> fdwCtrlType);
>> +
>> +switch (fdwCtrlType)
>> +{
>> +case CTRL_C_EVENT:
>> +case CTRL_BREAK_EVENT:
>> +sigterm_handler(SIGINT);
>> +return TRUE;
>> +
>> +case CTRL_CLOSE_EVENT:
>> +case CTRL_LOGOFF_EVENT:
>> +case CTRL_SHUTDOWN_EVENT:
>> +sigterm_handler(SIGTERM);
>> +return TRUE;
>> +
>> +default:
>> +av_log(NULL, AV_LOG_ERROR, "Received unknown windows signal
>> %d\n", fdwCtrlType);
>> +return FALSE;
>> +}
>> +}
>> +#endif
>> +
>> void term_init(void)
>> {
>> #if HAVE_TERMIOS_H
>> @@ -358,6 +386,9 @@ void term_init(void)
>> #ifdef SIGXCPU
>> signal(SIGXCPU, sigterm_handler);
>> #endif
>> +#ifdef HAVE_SETCONSOLECTRLHANDLER
>> +SetConsoleCtrlHandler((PHANDLER_ROUTINE)CtrlHandler, TRUE);
>> +#endif
>
> Why ffmpeg only? Can't this be in cmdutils.c to also work with the other
> tools?
It basically piggy backs on the existing signal handling code, which I
guess is FFmpeg only (probably each process needs to setup their own
signal handling). At least it'll be a nice example for people to use
if they need to :)
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Intel QSV encoder
You basically build it normally but build this as a library first: https://github.com/mjb2000/mfx_dispatch.git and configure with --enable-libmfx (NB that this mfx_dispatch thinger isn't compatible with windows XP so I don't use it personally): https://github.com/rdp/ffmpeg-windows-build-helpers/commit/c48af053657e174e270249e4b28a83c35897e320 GL! -r On 6/26/15, Cary Tetrick wrote: > Sorry, sent with wrong subject. > > Are there any patches supporting Intel QSV encoding that will work with > recent versions of ffmpeg on Windows? > Thanks. > ___ > 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] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C
On 6/25/15, Michael Niedermayer wrote: > On Wed, Jun 24, 2015 at 11:48:10PM -0600, Roger Pack wrote: >> On 6/24/15, Michael Niedermayer wrote: >> > On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote: >> >> On 7/5/12, Michael Niedermayer wrote: >> >> > On Mon, Jun 25, 2012 at 02:21:21PM +0200, Michael Niedermayer wrote: >> >> >> On Tue, Jun 19, 2012 at 07:10:04PM +0200, Reimar Döffinger wrote: >> >> >> > On 19 Jun 2012, at 11:31, Joe Wreschnig >> >> >> > wrote: >> >> >> > > On Windows, the Ctrl+Break key combination usually does what >> >> >> > > Ctrl+C >> >> >> > > does. It is more common for processes to send other processes >> >> >> > > Ctrl+Break rather than Ctrl+C, because sending Ctrl+C / SIGINT >> >> >> > > doesn't >> >> >> > > work if you started a child in a new process group. >> >> >> > > >> >> >> > > This patch makes ffmpeg.exe register what Windows calls a >> >> >> > > console >> >> >> > > control event handler, which allows it to intercept Ctrl+Break. >> >> >> > > It >> >> >> > > hands it off directly to the usual SIGINT/SIGTERM handler. The >> >> >> > > same >> >> >> > > function also processes closing the console window, mapping it >> >> >> > > to >> >> >> > > SIGTERM. >> >> >> > > >> >> >> > > Obviously, this is only enabled if compiling for a platform >> >> >> > > where >> >> >> > > SetConsoleCtrlHandler is available (i.e. modern Windows). >> >> >> > >> >> >> > What is "modern"? Also it is rather unusual to recompile for >> >> >> > different >> >> >> > Windows versions, couldn't you with about the same effort just >> >> >> > use >> >> >> > GetProcAddress (more complex code, but in exchange you'd save on >> >> >> > all >> >> >> > the >> >> >> > configure changes and #ifs). >> >> >> >> >> >> It seems versions that dont support this are no longer supported >> >> >> by microsoft. IMHO we shouldnt bother too much with such old >> >> >> windows >> >> >> versions unless someone wants to / volunteers to do it. >> >> >> >> >> >> thus, if there are no objections i will apply this patch once a few >> >> >> minor issues are fixed (ifdef breaking compile to be precisse) >> >> > >> >> > iam waiting for a working patch >> >> > i could try to fix it before applying myself but with patches for >> >> > non linux platforms i prefer to avoid changing as the changes would >> >> > be untested ,.. >> >> >> >> Sorry I dropped the ball on this one. >> >> See attached. The major gains we get out of this (in my head at >> >> least) is hopefully better shutdown if somebody logs out (which has >> >> bitten me before). Or if someone closes a console window which also >> >> shuts down FFmpeg. >> >> >> >> I noticed that even with handling notifications of "logout" that >> >> ffmpeg can still easily leave behind corrupted mp4 files (it gets >> >> killed quickly after). >> > >> >> Makes me wonder if there's some way to make it shutdown more quickly, >> >> but I'm not sure if it's a problem yet or not. >> > >> > iam not sure i understand ? >> > does windows kill the process immedeatly after CtrlHandler() returns? >> > if so CtrlHandler() should wait for the main loop to exit and cleanup >> > finishing before it returns >> >> Thanks for the pointer, you were exactly right. Appears I can >> basically "Sleep" in that method and thus allow FFmpeg to cleanup (in >> vista+ I believe it gives a max of 5 seconds which is enough). If >> there's some other easy way to know the main loop has exited I could >> use that I suppose, but it should have the same effect. > > you could set a global volatile variable to 1 at the end of > exit_program() and wait on that to happen in the handler Interesting. I think it's probably "the same finally behavior" either way, since exit will be called, and the entire process basically terminated, but it does feel cleaner slightly. . Attached is one that waits on a variable set in ffmpeg_cleanup (since I guess that's run after exit() is called?) if you like it more. Feel free to modify it to fit. In my experiments typically the process is terminated before it even has a chance to get past the Sleep(0) loop, but sometimes it does :) Cheers! -roger- 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C
On 6/30/15, Michael Niedermayer wrote: > On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote: > [...] >> +Sleep(0); > > the funky line ending is here OK try this one. thanks! 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C
On 6/30/15, Michael Niedermayer wrote: > On Tue, Jun 30, 2015 at 01:00:22PM -0600, Roger Pack wrote: >> On 6/30/15, Michael Niedermayer wrote: >> > On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote: >> >> > [...] >> >> >> +Sleep(0); >> >> > >> >> > the funky line ending is here >> >> OK try this one. >> thanks! > >> configure |2 ++ >> ffmpeg.c | 41 + >> 2 files changed, 43 insertions(+) >> ff3f339e550dc83d300346ec648f778f85900679 >> 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch >> From 7ce401dbd16873928bd541d5d567208963b85889 Mon Sep 17 00:00:00 2001 >> From: rogerdpack >> Date: Tue, 30 Jun 2015 12:58:43 -0600 >> Subject: [PATCH] windows: respond to logoff and ctrl+break messages as >> well >> >> Signed-off-by: rogerdpack >> --- >> configure | 2 ++ >> ffmpeg.c | 41 + >> 2 files changed, 43 insertions(+) >> >> diff --git a/configure b/configure >> index 89b5668..cc23991 100755 >> --- a/configure >> +++ b/configure >> @@ -1787,6 +1787,7 @@ SYSTEM_FUNCS=" >> pthread_cancel >> sched_getaffinity >> SetConsoleTextAttribute >> +SetConsoleCtrlHandler >> setmode >> setrlimit >> Sleep >> @@ -4990,6 +4991,7 @@ check_func_headers windows.h >> GetSystemTimeAsFileTime >> check_func_headers windows.h MapViewOfFile >> check_func_headers windows.h PeekNamedPipe >> check_func_headers windows.h SetConsoleTextAttribute >> +check_func_headers windows.h SetConsoleCtrlHandler >> check_func_headers windows.h Sleep >> check_func_headers windows.h VirtualAlloc >> check_struct windows.h "CONDITION_VARIABLE" Ptr >> diff --git a/ffmpeg.c b/ffmpeg.c >> index aac03bb..b58d891 100644 >> --- a/ffmpeg.c >> +++ b/ffmpeg.c >> @@ -79,6 +79,10 @@ >> #include >> #include >> #endif >> +#ifdef HAVE_SETCONSOLECTRLHANDLER > [...] >> +#ifdef HAVE_SETCONSOLECTRLHANDLER > > they are defined but to 0 on linux, this needs #if OK see attached, thanks. -roger- 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] PATCH: log more information on failure to init simple filter graph
See attached. Feel free to adjust it, but having more information helped me a bit today. Cheers! -roger- 0001-log-more-information-on-failure-to-init-simple-filte.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] request for feedback on video codec idea
Lacking a better place to debate this, I would like to ask some
questions on a video codec idea...
The goal is basically to create a very fast lossless screen capture
codec (i.e. in the input there will be lots of repeated "colors" of
neighboring pixels, not a lot of dynamic content between frames).
I have become aware of some "fast" compression tools like LZO, LZ4,
density, etc. It seems like they all basically compress "the first
64KB then the next 64KB" or something like that [1].
My idea is to basically put pixels of the same position, from multiple
frames, "together" in a stream, then apply normal (fast) compression
algorithms to the stream. The hope being that if the pixels are the
"same" between frames (presumed to be so because of not much dynamic
content), the compression will be able to detect the similarity and
compress it well.
For instance, given 3 frames of video ("one after another" from the
incoming video stream), "combine them" into one stream like:
pixel 1 frame 1, pixel 1 frame 2, pixel 1 frame 3, pixel 2 frame 2,
pixel 2 frame 2, pixel 2 frame 3 ...
then basically apply LZ4 or density algorithm to those bytes.
The theory being that if there is a lot of repeated content between
frames, it will compress well.
The basic need/desire for this was that huffyuv, though super fast at
encoding (it basically zips the frame), seems to create *huge* files,
I assume because "each frame is an I-frame" so it has to re encode
everything each frame. And also the egotistical desire to create the
"fastest video codec in existence" in case the same were useful in
other situations (i.e. use very little cpu--even huffyuv uses quite a
bit of cpu) :)
Any feedback on the concept?
Also does anything similar to this already exist? (though should I
create my new codec, it would be open source of course, which is
already different than many [probably efficient] screen capture codecs
out there).
Thanks.
-roger-
[1] http://fastcompression.blogspot.com/2011/05/lz4-explained.html
search for "64" it has some kind of concept of a sliding window, or
perhaps that's just the frame API dunno.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: gdigrab work for DPI in windows
On 10/28/15, Matt Oliver wrote:
> On 5 October 2015 at 20:05, Matt Oliver wrote:
>
>> On 5 October 2015 at 19:29, Matt Oliver wrote:
>>
>>> On 30 September 2015 at 02:48, wm4 wrote:
>>>
>>>> On Wed, 23 Sep 2015 12:04:43 -0600
>>>> Roger Pack wrote:
>>>>
>>>> > From 6a972dda58bd5ab31524cd4e5326b4bcdeaeaa8c Mon Sep 17 00:00:00 2001
>>>> > From: rogerdpack
>>>> > Date: Wed, 23 Sep 2015 12:03:27 -0600
>>>> > Subject: [PATCH] gdigrab: grab right desktop size if DPI in use, based
>>>> on
>>>> > patch from Alexander Brotzge
>>>> >
>>>> > Signed-off-by: rogerdpack
>>>> > ---
>>>> > libavdevice/gdigrab.c | 44
>>>> +---
>>>> > 1 file changed, 29 insertions(+), 15 deletions(-)
>>>> >
>>>> > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
>>>> > index 9a185d4..b0faf45 100644
>>>> > --- a/libavdevice/gdigrab.c
>>>> > +++ b/libavdevice/gdigrab.c
>>>> > @@ -235,6 +235,9 @@ gdigrab_read_header(AVFormatContext *s1)
>>>> > AVStream *st = NULL;
>>>> >
>>>> > int bpp;
>>>> > +int vertres;
>>>> > +int desktopvertres;
>>>> > +float scale;
>>>> > RECT virtual_rect;
>>>> > RECT clip_rect;
>>>> > BITMAP bmp;
>>>> > @@ -263,14 +266,34 @@ gdigrab_read_header(AVFormatContext *s1)
>>>> > goto error;
>>>> > }
>>>> >
>>>> > -if (hwnd) {
>>>> > -GetClientRect(hwnd, &virtual_rect);
>>>> > -} else {
>>>> > +/* This will get the device context for the selected window, or
>>>> > if
>>>> > + * none, the primary screen */
>>>> > +source_hdc = GetDC(hwnd);
>>>> > +if (!source_hdc) {
>>>> > +WIN32_API_ERROR("Couldn't get window device context");
>>>> > +ret = AVERROR(EIO);
>>>> > +goto error;
>>>> > +}
>>>> > +bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
>>>> > +
>>>> > +scale = 1.0;
>>>> > +if (hwnd == NULL) {
>>>> > + /* desktop -- get the right height and width for scaling DPI */
>>>> > + vertres = GetDeviceCaps(source_hdc, VERTRES);
>>>> > + desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
>>>> > + scale = (float) desktopvertres / (float) vertres;
>>>> > +}
>>>>
>>>
>>> This seems a little redundant as scale is only being set when hwnd is
>>> null however in the below lines its then being used in the opposite
>>> conditional. Since this checks for hwnd essentially being non null then
>>> scale is always going to be the inital value of 1.
>>>
>>>
>>>> > + if (hwnd) {
>>>> > + GetClientRect(hwnd, &virtual_rect);
>>>> > + virtual_rect.right = virtual_rect.right * scale;
>>>> > + virtual_rect.bottom = virtual_rect.bottom * scale;
>>>> > + } else {
>>>> > virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN);
>>>> > virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN);
>>>> > -virtual_rect.right = virtual_rect.left +
>>>> GetSystemMetrics(SM_CXVIRTUALSCREEN);
>>>> > -virtual_rect.bottom = virtual_rect.top +
>>>> GetSystemMetrics(SM_CYVIRTUALSCREEN);
>>>> > -}
>>>> > +virtual_rect.right = (virtual_rect.left +
>>>> GetSystemMetrics(SM_CXVIRTUALSCREEN)) * scale;
>>>> > +virtual_rect.bottom = (virtual_rect.top +
>>>> GetSystemMetrics(SM_CYVIRTUALSCREEN)) * scale;
>>>> > + }
>>>>
>>>
>>> This if else could be combined with the above if as scale is only a value
>>> different to 1 in the 'else' case. Also as wm4 said it would probably be
>>> better to keep the scale factors as ints.
>>>
>>>
>>>> >
>>>> > /* If no width or height set, use full screen/window area */
>>>> > if (!gdigrab->width || !gdigrab->height) {
>>>> > @@ -299,15 +322,6 @@ gdigrab_read_header(AVFormatContext *s1)
>>>> > goto error;
>>>> > }
>>>> >
>>>> > -/* This will get the device context for the selected window, or
>>>> > if
>>>> > - * none, the primary screen */
>>>> > -source_hdc = GetDC(hwnd);
>>>> > -if (!source_hdc) {
>>>> > -WIN32_API_ERROR("Couldn't get window device context");
>>>> > -ret = AVERROR(EIO);
>>>> > -goto error;
>>>> > -}
>>>> > -bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
>>>> >
>>>> > if (name) {
>>>> > av_log(s1, AV_LOG_INFO,
>>>
>>>
>>> However I think the basic dpi scaling technique is correct. However I
>>> would think it should be more along the lines of the modifications Ive
>>> attached.
>>>
>>
>> Woops, allow me to try that again without windows messing up the patches
>> line endings.
>>
>
> Does anyone have any issues with the updated patch or can it be pushed?
OK sorry for the delay finally got around to testing it and LGTM
recommend commit (I'm a gdigrab maintainer).
Cheers!
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] request for feedback on video codec idea
On 10/14/15, Nicolas George wrote:
> Le tridi 23 vendémiaire, an CCXXIV, Roger Pack a écrit :
>> For instance, given 3 frames of video ("one after another" from the
>> incoming video stream), "combine them" into one stream like:
>> pixel 1 frame 1, pixel 1 frame 2, pixel 1 frame 3, pixel 2 frame 2,
>> pixel 2 frame 2, pixel 2 frame 3 ...
>>
>> then basically apply LZ4 or density algorithm to those bytes.
>>
>> The theory being that if there is a lot of repeated content between
>> frames, it will compress well.
>
> Standard answer: profile, don't speculate.
>
> I have no idea if this can prove promising, but I am pretty sure you could
> implement enough of it to get an estimate in just a few minutes with your
> language of choice.
>
> Choose a test clip that has convenient properties (frame size multiple of
> your chosen block size, number of frames multiple of the frame group size,
> etc.).
>
> In the program, hardcode the frame size, pixel format, etc., and forego
> error checks. Read a group of frames from standard input, assuming rawvideo
> format, then output the pixels to standard output in the order you want.
>
> Run with standard input piped from ffmpeg to get the rawvideo contents and
> standard output piped to your favorite command-line stream compression
> utility (gzip, xz).
>
> If the result looks promising, enhance. If not, you know you tried.
Great idea. I think I will do that.
I did get as far as "single frame" encoding using lzo.
It works *great* for synthetically generated data like testsrc. I
mean like twice as fast as anything else, with better compression LOL.
With real data, not so much. I'm attaching it here not for it to be
committed but for followers in case it saves anybody some time that
also wants to go down this path.
I will hopefully find time to work on the "multi frame" aspect soon,
and probably save time by doing what you suggested there.
Thanks!
diff --git a/configure b/configure
index a30d831..43108e4 100755
--- a/configure
+++ b/configure
@@ -1961,6 +1961,8 @@ CONFIG_EXTRA="
hpeldsp
huffman
huffyuvdsp
+rzipenc
+rzipdec
huffyuvencdsp
idctdsp
iirfilter
@@ -2283,6 +2285,8 @@ hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser
qsvdec hevc_qsv_hwacce
hevc_qsv_encoder_select="qsvenc"
huffyuv_decoder_select="bswapdsp huffyuvdsp llviddsp"
huffyuv_encoder_select="bswapdsp huffman huffyuvencdsp llviddsp"
+rzip_encoder_select="lzo"
+#rzip_decoder_select="lzo"
iac_decoder_select="imc_decoder"
imc_decoder_select="bswapdsp fft mdct sinewin"
indeo3_decoder_select="hpeldsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d85215d..d54d0ff 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -310,6 +310,8 @@ OBJS-$(CONFIG_HNM4_VIDEO_DECODER) += hnm4video.o
OBJS-$(CONFIG_HQ_HQA_DECODER) += hq_hqa.o hq_hqadata.o hq_hqadsp.o \
canopus.o
OBJS-$(CONFIG_HQX_DECODER) += hqx.o hqxvlc.o hqxdsp.o canopus.o
+OBJS-$(CONFIG_RZIP_DECODER)+= rzip.o rzipdec.o
+OBJS-$(CONFIG_RZIP_ENCODER)+= rzip.o rzipenc.o
OBJS-$(CONFIG_HUFFYUV_DECODER) += huffyuv.o huffyuvdec.o
OBJS-$(CONFIG_HUFFYUV_ENCODER) += huffyuv.o huffyuvenc.o
OBJS-$(CONFIG_IDCIN_DECODER) += idcinvideo.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 9f60d7c..7335b24 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -203,6 +203,7 @@ void avcodec_register_all(void)
REGISTER_DECODER(HQ_HQA,hq_hqa);
REGISTER_DECODER(HQX, hqx);
REGISTER_ENCDEC (HUFFYUV, huffyuv);
+REGISTER_ENCDEC (RZIP, rzip);
REGISTER_DECODER(IDCIN, idcin);
REGISTER_DECODER(IFF_ILBM, iff_ilbm);
REGISTER_DECODER(INDEO2,indeo2);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5e36c94..33c3cd6 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -130,6 +130,7 @@ enum AVCodecID {
AV_CODEC_ID_SVQ3,
AV_CODEC_ID_DVVIDEO,
AV_CODEC_ID_HUFFYUV,
+AV_CODEC_ID_RZIP,
AV_CODEC_ID_CYUV,
AV_CODEC_ID_H264,
AV_CODEC_ID_INDEO3,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9cad3e6..616069b 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -188,6 +188,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
},
{
+.id= AV_CODEC_ID_RZIP,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "RZIP",
+.long_name = NULL_IF_CONFIG_SMALL("Rzip"),
+.props = A
Re: [FFmpeg-devel] request for feedback on video codec idea
On 10/14/15, Hendrik Leppkes wrote:
> On Wed, Oct 14, 2015 at 8:08 PM, Roger Pack wrote:
>> Lacking a better place to debate this, I would like to ask some
>> questions on a video codec idea...
>>
>> The goal is basically to create a very fast lossless screen capture
>> codec (i.e. in the input there will be lots of repeated "colors" of
>> neighboring pixels, not a lot of dynamic content between frames).
>>
>> I have become aware of some "fast" compression tools like LZO, LZ4,
>> density, etc. It seems like they all basically compress "the first
>> 64KB then the next 64KB" or something like that [1].
>>
>> My idea is to basically put pixels of the same position, from multiple
>> frames, "together" in a stream, then apply normal (fast) compression
>> algorithms to the stream. The hope being that if the pixels are the
>> "same" between frames (presumed to be so because of not much dynamic
>> content), the compression will be able to detect the similarity and
>> compress it well.
>>
>> For instance, given 3 frames of video ("one after another" from the
>> incoming video stream), "combine them" into one stream like:
>> pixel 1 frame 1, pixel 1 frame 2, pixel 1 frame 3, pixel 2 frame 2,
>> pixel 2 frame 2, pixel 2 frame 3 ...
>>
>> then basically apply LZ4 or density algorithm to those bytes.
>>
>> The theory being that if there is a lot of repeated content between
>> frames, it will compress well.
>>
>> The basic need/desire for this was that huffyuv, though super fast at
>> encoding (it basically zips the frame), seems to create *huge* files,
>> I assume because "each frame is an I-frame" so it has to re encode
>> everything each frame. And also the egotistical desire to create the
>> "fastest video codec in existence" in case the same were useful in
>> other situations (i.e. use very little cpu--even huffyuv uses quite a
>> bit of cpu) :)
>>
>> Any feedback on the concept?
>> Also does anything similar to this already exist? (though should I
>> create my new codec, it would be open source of course, which is
>> already different than many [probably efficient] screen capture codecs
>> out there).
>>
>> Thanks.
>> -roger-
>>
>
> I can't really comment on the merits of this compression scheme, but
> note that you might have trouble with the ffmpeg API when handling
> such a codec, since every single data packet would result in X output
> frames (3 in your example) - this is not a scheme that avcodec can
> really represent well.
> On top of that, containers might have troubles timestamping this properly.
True, I had hoped that FFmpeg would have some "b frame" type
functionality that I could leverage somehow...or perhaps I can fake it
by using null frames or something along those lines.
Cheers!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Cyrillic devices name support in libavdevice/dshow
On 12/14/15, Michael Savin wrote: > Hi, please review this patch for cyrillic devices name support in > libavdevice/dshow. > Bug described here: https://trac.ffmpeg.org/ticket/5045 Still mulling over why this would be needed...hm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress
On 8/22/15, Michael Niedermayer wrote: > On Sat, Aug 22, 2015 at 05:18:04AM +0200, Máté Sebők wrote: >> > >> > fails to build with mingw due to missing header >> > In file included from ffmpeg/libavdevice/dshow.c:33:0: >> > ffmpeg/libavdevice/bdadefs.h:8:24: fatal error: combaseapi.h: No such >> > file or directory >> > compilation terminated. >> > make: *** [libavdevice/dshow.o] Error 1 >> > maybe a header check is needed in configure >> >> >> Maybe fixed... unnecessary headers removed (also some cleanup in the >> interface-descriptions) > > i can confirm, the new patch builds fine with mingw here > > > [...] > >> > + >> > > +gfilename = malloc((strlen(ctx->dtv_graph_ >> > file)+4)*sizeof(WCHAR)); >> > is this intended to be malloc() instead of av_malloc() ? >> >> >> Yes, it was intended, only a filename buffer for char-to-widechar >> conversion. > > normally code in FFmpeg uses av_malloc() unless there is need for > the buffer to be passed into external functions which require a > different allocation > > full review left to roger and anyone else who wants to review OK I had this great idea to capture the incoming MPEG2 transport stream from the digital TV capture device. Kind of like "raw" stream, so FFmpeg could have access to, for instance, all the audio stream. It appears that the type coming out of the tuner is: MEDIATYPE_Stream with subtype KSDATAFORMAT_SUBTYPE_BDA_MPEG2_TRANSPORT which is apparently treated the same as MEDIASUBTYPE_MPEG2_TRANSPORT by the built in directshow mpeg demuxer [1] so I assume is some kind of typical MPEG2 TS stream. I had hoped that if I set dshow's AVStream's codec_id to codec->codec_id = AV_CODEC_ID_NONE; codec->codec_type = AVMEDIA_TYPE_DATA; That it would somehow recognize that I was sending it an MPEG stream and insert an appropriate demuxer for me. However, when I run it, it fails like this: Input #0, dshow, from 'video=Hauppauge WinTV 885 BDA Tuner/Demod': Duration: N/A, bitrate: N/A Codec 0x2 is not in the full list. Stream #0:0, 0, 1/2700: Data: unknown_codec, 0/1 Successfully opened the file. Output #0, mp4, to 'yo.mp4': Output file #0 does not contain any stream so it's definitely not, for instance, doing a probe or analyze on the MPEG stream Is this possible or any hints/tips/tricks I could possibly use? Thanks! [1] https://msdn.microsoft.com/en-us/library/windows/desktop/dd390716(v=vs.85).aspx ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress
On 12/17/15, Roger Pack wrote: > On 8/22/15, Michael Niedermayer wrote: >> On Sat, Aug 22, 2015 at 05:18:04AM +0200, Máté Sebők wrote: >>> > >>> > fails to build with mingw due to missing header >>> > In file included from ffmpeg/libavdevice/dshow.c:33:0: >>> > ffmpeg/libavdevice/bdadefs.h:8:24: fatal error: combaseapi.h: No such >>> > file or directory >>> > compilation terminated. >>> > make: *** [libavdevice/dshow.o] Error 1 >>> > maybe a header check is needed in configure >>> >>> >>> Maybe fixed... unnecessary headers removed (also some cleanup in the >>> interface-descriptions) >> >> i can confirm, the new patch builds fine with mingw here >> >> >> [...] >> >>> > + >>> > > +gfilename = malloc((strlen(ctx->dtv_graph_ >>> > file)+4)*sizeof(WCHAR)); >>> > is this intended to be malloc() instead of av_malloc() ? >>> >>> >>> Yes, it was intended, only a filename buffer for char-to-widechar >>> conversion. >> >> normally code in FFmpeg uses av_malloc() unless there is need for >> the buffer to be passed into external functions which require a >> different allocation >> >> full review left to roger and anyone else who wants to review > > OK I had this great idea to capture the incoming MPEG2 transport > stream from the digital TV capture device. Kind of like "raw" stream, > so FFmpeg could have access to, for instance, all the audio stream. > > It appears that the type coming out of the tuner is: > MEDIATYPE_Stream > with subtype > KSDATAFORMAT_SUBTYPE_BDA_MPEG2_TRANSPORT > which is apparently treated the same as MEDIASUBTYPE_MPEG2_TRANSPORT > by the built in directshow mpeg demuxer [1] so I assume is some kind > of typical MPEG2 TS stream. > > I had hoped that if I set dshow's AVStream's codec_id to > codec->codec_id = AV_CODEC_ID_NONE; > codec->codec_type = AVMEDIA_TYPE_DATA; > > That it would somehow recognize that I was sending it an MPEG stream > and insert an appropriate demuxer for me. > > However, when I run it, it fails like this: > > Input #0, dshow, from 'video=Hauppauge WinTV 885 BDA Tuner/Demod': > Duration: N/A, bitrate: N/A > Codec 0x2 is not in the full list. > Stream #0:0, 0, 1/2700: Data: unknown_codec, 0/1 I guess to avoid this I can expose my device as a "URLProtocol" as well as a AVInputFormat or some odd? One option to work around it is to capture from the "mpeg2video" pin in the graph. My next problem appears to be that directshow "feeds" me the mpeg2video packets in "ts" sized chunks (i.e. 8K or smaller). It appears to me that the native mpeg2video decoder doesn't know how to handle partial packets like that and proceeds to basically just render the top part of frames. Any suggestions there? Also even if I dump the mpeg stream "to file" and play that with ffmpeg, a few artifacts appear to be introduced. Anybody know if libmpeg2 is better at decoding, somehow, than the native mpeg2video decoder, by chance, artifact wise? I doubt it but thought I'd check. Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/libvo-aac: Mark the encoder as experimental
On 12/11/15, Lou Logan wrote: > On Wed, 9 Dec 2015 21:24:06 +0100, Hendrik Leppkes wrote: > >> libvo-aacenc doesn't see any development anymore. >> Its an encoder taken from the android sdk a long time ago, but AOSP >> replaced it with fdk-aac, so libvo-aacenc is EOL. >> >> And its quality is horrible. Maybe just output a warning message for now with their alternatives... > We should remove the wrapper. I'm tired to telling users to use a > different encoder–especially when they try to encode more than 2 > channels and get a non-informative error: > > [libvo_aacenc @ 0x3211780] Unable to set encoding parameters Maybe we should modify that message to be more helpful as well :) -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress
> OK I had this great idea to capture the incoming MPEG2 transport
> stream from the digital TV capture device. Kind of like "raw" stream,
> so FFmpeg could have access to, for instance, all the audio stream.
>
> It appears that the type coming out of the tuner is:
> MEDIATYPE_Stream
> with subtype
> KSDATAFORMAT_SUBTYPE_BDA_MPEG2_TRANSPORT
> which is apparently treated the same as MEDIASUBTYPE_MPEG2_TRANSPORT
> by the built in directshow mpeg demuxer [1] so I assume is some kind
> of typical MPEG2 TS stream.
>
> I had hoped that if I set dshow's AVStream's codec_id to
> codec->codec_id = AV_CODEC_ID_NONE;
> codec->codec_type = AVMEDIA_TYPE_DATA;
Oops that was meant to be
codec->codec_id = AV_CODEC_ID_MPEG2TS;
codec->codec_type = AVMEDIA_TYPE_DATA;
> That it would somehow recognize that I was sending it an MPEG stream
> and insert an appropriate demuxer for me.
>
> However, when I run it, it fails like this:
>
> Input #0, dshow, from 'video=Hauppauge WinTV 885 BDA Tuner/Demod':
> Duration: N/A, bitrate: N/A
> Codec 0x2 is not in the full list.
> Stream #0:0, 0, 1/2700: Data: unknown_codec, 0/1
> Successfully opened the file.
> Output #0, mp4, to 'yo.mp4':
> Output file #0 does not contain any stream
>
> so it's definitely not, for instance, doing a probe or analyze on the
> MPEG stream
>
> Is this possible or any hints/tips/tricks I could possibly use?
To answer my own question, I turned the dshow capture device into both
an AVInputFormat *and* a URLProtocol that "wraps" the AVInputFormat.
Apparently ffmpeg can receive "raw" bytes only from URLProtocol (?)
This way worked great both "segmented" MPEG2VIDEO streams as well as
"raw" MPEG TS streams.
Still a bit unexpected to be necessary, but in case its interesting to
followers, here was the wrapper code (will hopefully be committed to
git trunk soon'ish once I clean it up).
Thanks all.
-roger-
static int dshow_url_open(URLContext *h, const char *filename, int flags)
{
struct dshow_ctx *ctx = h->priv_data;
if (!(ctx->protocol_av_format_context = avformat_alloc_context()))
return AVERROR(ENOMEM);
ctx->protocol_av_format_context->flags = h->flags;
av_strstart(filename, "dshowbda:", &filename); // remove prefix "dshowbda:"
if (filename)
av_strlcpy(ctx->protocol_av_format_context->filename, filename,
1024); // 1024 max bytes
ctx->protocol_av_format_context->iformat = &ff_dshow_demuxer;
ctx->protocol_latest_packet = av_packet_alloc();
ctx->protocol_latest_packet->pos = 0; // default is -1
if (!ctx->protocol_latest_packet)
return AVERROR(ENOMEM);
ctx->protocol_av_format_context->priv_data = ctx; // a bit
circular, but needed to pass through the settings
return dshow_read_header(ctx->protocol_av_format_context);
}
static int dshow_url_read(URLContext *h, uint8_t *buf, int max_size)
{
struct dshow_ctx *ctx = h->priv_data;
int packet_size_or_fail;
int bytes_to_copy;
int bytes_left = ctx->protocol_latest_packet->size -
ctx->protocol_latest_packet->pos;
if (bytes_left == 0) {
av_packet_unref(ctx->protocol_latest_packet);
packet_size_or_fail =
dshow_read_packet(ctx->protocol_av_format_context,
ctx->protocol_latest_packet);
if (packet_size_or_fail < 0)
return packet_size_or_fail;
av_assert0(ctx->protocol_latest_packet->stream_index == 0); //
this should be a stream based, so only one stream, so always index 0
av_assert0(packet_size_or_fail ==
ctx->protocol_latest_packet->size); // should match...
ctx->protocol_latest_packet->pos = 0; // default is -1
bytes_left = ctx->protocol_latest_packet->size -
ctx->protocol_latest_packet->pos;
av_log(h, AV_LOG_VERBOSE, "dshow_url_read read packet of size
%d\n", ctx->protocol_latest_packet->size);
}
bytes_to_copy = FFMIN(bytes_left, max_size);
if (bytes_to_copy != bytes_left)
av_log(h, AV_LOG_DEBUG, "passing partial dshow packet %d >
%d\n", bytes_left, max_size);
memcpy(buf,
&ctx->protocol_latest_packet->data[ctx->protocol_latest_packet->pos],
bytes_to_copy);
ctx->protocol_latest_packet->pos += bytes_to_copy;
av_log(h, AV_LOG_VERBOSE, "dshow_url_read returning %d\n", bytes_to_copy);
return bytes_to_copy;;
}
static int dshow_url_close(URLContext *h)
{
struct dshow_ctx *ctx = h->priv_data;
int ret = dshow_read_close(ctx->protocol_av_format_context);
ctx->protocol_av_format_context->priv_data = NULL; // just in case
it would be freed below
avformat_free_context(ctx->protocol_av_format_context);
av_packet_free(&ctx->protocol_latest_packet); // free wrapper,
also does an unref
return ret;
}
Thanks!
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP] SDL2 in ffplay
On 1/2/16, Marton Balint wrote: > Hi, > > To anybody who is interested, I have pushed my experimental SDL2 branch of > ffplay to github. (https://github.com/cus/ffplay.git) > > SDL2 completely replaced SDL_Overlay with 3D textures, so with SDL2 it is > possible to: > - Use textures with odd width/height > - Use RGB textures, not only YUV > - Use the renderer to present subtitles with alpha channel > on top of the video instead of software blending Perhaps you could update the "sdl out" filter as well? :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header
On 12/10/15, Philip Langdale wrote: > On 2015-12-09 21:34, wm4 wrote: >> On Mon, 7 Dec 2015 19:34:20 +0100 >> Timo Rothenpieler wrote: >> >>> > I don't remember if this was discussed when avisynth and other headers >>> > where included, but what's the advantage of directly including the >>> > header and burden the FFmpeg sources, rather than asking the user to >>> > download them in case of need? >>> >>> The nvenc sdk isn't exactly a common thing that distributions provide. >>> As distributions can now easily ship ffmpeg with nvenc support, this >>> propably helps users who now no longer need to build ffmpeg themselves >>> for nvenc support. >> >> So why would distros build with nvenc support, if they can't even do a >> simple thing like installing a single header file? >> >> Are we really talking about including a huge 3rd party header because >> distros are so lazy? What's next, do we add Windows headers to the >> FFmpeg tree, because MinGW lags severely behind the newest definitions >> like HEVC DXVA support? >> >> We could just provide a download link for the nvenc header somewhere if >> the problem is finding the header. > > Admittedly, we are solving someone else's problem, but the header is > buried inside the SDK download which is hidden behind a click-through on > nvidia's web page. So it's not made available in a way that is readily > consumable by an end user or by a distribution vendor. I have had some success scripting its download in the past, FWIW :) Cheers! -roger- echo "installing nvenc [nvidia gpu assisted encoder]" curl http://developer.download.nvidia.com/assets/cuda/files/nvidia_video_sdk_6.0.1.zip -O -L unzip nvidia_video_sdk_6.0.1.zip cp nvidia_video_sdk_6.0.1/Samples/common/inc/* $mingw_w64_x86_64_prefix/include ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add SOFAlizer audio filter
On 12/10/15, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > Lite version of one sent to VLC mailing list with only slow but high quality > mode present. > To use you need recent netCDF library, SOFA file(s), multichannel audio and > headphones. Could you post an example or step by step instructions of using this, for followers? A specific SOFA file, for instance, etc. Cheers! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] have some major changes for nvenc support
On 11/5/15, wm4 wrote: > On Thu, 5 Nov 2015 16:23:04 +0800 > Agatha Hu wrote: > >> 2) We use AVFrame::opaque field to store a customized ffnvinfo struture >> to prevent expensive CPU<->GPU transferration. Without it, the workflow >> will be like CPU AVFrame input-->copy to GPU-->do CUDA resizing-->copy >> to CPU AVFrame-->copy to GPU-->NVENC encoding. And now it becomes: >> CPU AVFrame input-->copy to GPU-->do CUDA resizing-->NVENC encoding. >> Our strategy is to check whether AVFrame::opaque is not null AND its >> first 128 bytes matches some particular GUID. If so, AVFrame::opaque is >> a valid ffnvinfo struture and we read GPU address directly from it >> instead of copying data from AVFrame. > > Please no, not another hack that makes the hw decoding API situation > worse. Do this properly and coordinate with Gwenole Beauchesne, who > plans improvements into this direction. Which part are you referring to (though I'll admit putting some stuff in libavutil seems a bit suspect). It would be nice to have the nvresize filter available anyway, and it looks like it mostly just deals with private context variables. Cheers! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] have some major changes for nvenc support
On 1/8/16, Andrey Turkin wrote: > In my opinion this proliferation of various filters which do the same thing > in different way is a configuration headache. There's CPU filters: one for > scaling/format conversion, one for padding, one for cropping, like 5 > different filters for deinterlacing. And now there would be nvresize for > scaling, and we gotta add CUDA-based nvpad and nvdeint if we want to do > some transcoding. Maybe add overlaying too - so nvoverlay. Then there is > OpenCL which can do everything - so 4 more filters for that. And there is > quicksync which I think can do those things, so there would be qsvscale and > qsvdeint. And there is D3D11 video processor which can do those things too > (simultaneously in fact), so there's gotta be > d3d11vascaledeintpadcropoverlay. And then we've got a whole bunch of video > filters which can only do their job on a specific hwaccel platform. Want to > try different hwaccel? Rewrite damn filter string. Want to do something > generic that can be used over different platforms? Can't be done. > Maybe it's just my wishful thinking, but I was wondering for some time if > there can be one "smart" filter to do one specific thing? Yes a smart wrapper might be nice. I'm all for different ways to resize, though, I used to wonder why there wasn't a filter option liek -filter_complex "convert_to_opengl; opengl_resize=1000x1000; opengl_rotate=90;convert_from_opengl;" that type of thing, I think based on similar functionality gstreamer has. Cheers! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
