Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to openh264 1.6
On Mon, Mar 07, 2016 at 06:05:30PM +0100, Stefano Sabatini wrote: > In particular, the slice mode API was changed in commit: > > commit 33c378f7b791310e4cb64b53e2bb8f3f3bded105 > Author: sijchen > Date: Tue Nov 10 09:50:06 2015 -0800 > > change API for slicing part for easier usage (the UseLoadBalancing flag > is still under working) > > This fixes compilation with latest version of openh264. > --- > configure | 2 +- > doc/encoders.texi | 25 ++- > libavcodec/libopenh264enc.c | 48 > ++--- > libavcodec/version.h| 2 +- > 4 files changed, 42 insertions(+), 35 deletions(-) as one testing ffmpeg with openh264 (building at least) i have mixed feelings about this, it would cause me to drop further testing with openh264 in all releases OR in git master because releases wont build with git master of openh264 and master wont build with older openh264 having 2 different versions installed would be possible but i will not go to that troubble and i suspect noone else will either [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] [v2] libavcodec/options.c: handle hw_frames_ctx where necessary
avcodec_copy_context didn't handle hw_frames_ctx references correctly which
could cause crashes.
---
Changes from v1: reverted changes to avcodec_free_context
libavcodec/options.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index ea2563b..08c2259 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -197,6 +197,7 @@ int avcodec_copy_context(AVCodecContext *dest, const
AVCodecContext *src)
av_freep(&dest->inter_matrix);
av_freep(&dest->extradata);
av_freep(&dest->subtitle_header);
+av_buffer_unref(&dest->hw_frames_ctx);
memcpy(dest, src, sizeof(*dest));
av_opt_copy(dest, src);
@@ -225,6 +226,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
dest->inter_matrix= NULL;
dest->rc_override = NULL;
dest->subtitle_header = NULL;
+dest->hw_frames_ctx = NULL;
#define alloc_and_copy_or_fail(obj, size, pad) \
if (src->obj && size > 0) { \
@@ -245,6 +247,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
av_assert0(dest->subtitle_header_size == src->subtitle_header_size);
#undef alloc_and_copy_or_fail
+if (src->hw_frames_ctx) {
+dest->hw_frames_ctx = av_buffer_ref(src->hw_frames_ctx);
+if (!dest->hw_frames_ctx)
+goto fail;
+}
+
return 0;
fail:
@@ -255,6 +263,7 @@ fail:
av_freep(&dest->subtitle_header);
dest->subtitle_header_size = 0;
dest->extradata_size = 0;
+av_buffer_unref(&dest->hw_frames_ctx);
av_opt_free(dest);
return AVERROR(ENOMEM);
}
--
2.7.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/adpcm: Support baby monitor adpcm_ms
On 5/5/16, Carl Eugen Hoyos wrote: > Paul B Mahol gmail.com> writes: > >> >> There is clearly overread if you ignore >> >> first two bytes. >> > >> > How can I reproduce the overread? >> >> By decoding file, looking at ffmpeg output. > > I did that and I don't see an overread: > What do I miss? This specific file have audio packets of size 1984 and last one of 1178. block align is 60. That gives as 30 bytes for each channel. Clearly there are extra 2 bytes before each adpcm stream which can be anything. Instead of checking data in stream why not check size of packet and act according to that and block align? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit
Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit
On 5/20/16, foo86 wrote: > Ping. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit
2016-05-13 11:48 GMT+02:00 foo86 : > -unsigned int v = get_unary(gb, 1, 128); > +unsigned int v = get_unary(gb, 1, get_bits_left(gb)); Not that the patch is not ok, but I have a few uneducated questions: 1) Given the get_bits_long(gb, k) afterwards, won't that code cause overreads for corrupted bitstreams? 2) I haven't checked the calling code, but consequently, wouldn't it be better to first check that at least k+1 bits are available? 3) 128 is already fairly large; is the new code for valid bitstreams (in the sense of specs and actually generated) or for corrupted bitstreams? I don't know where the parsing is validated afterwards (e.g. if there have been overreads or invalid values parsed) Thanks, -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit
On 5/20/16, Christophe Gisquet wrote: > 2016-05-13 11:48 GMT+02:00 foo86 : >> -unsigned int v = get_unary(gb, 1, 128); >> +unsigned int v = get_unary(gb, 1, get_bits_left(gb)); > > Not that the patch is not ok, but I have a few uneducated questions: > 1) Given the get_bits_long(gb, k) afterwards, won't that code cause > overreads for corrupted bitstreams? No, because checking for overreads is enabled. > 2) I haven't checked the calling code, but consequently, wouldn't it > be better to first check that at least k+1 bits are available? > 3) 128 is already fairly large; is the new code for valid bitstreams > (in the sense of specs and actually generated) or for corrupted > bitstreams? I don't know where the parsing is validated afterwards > (e.g. if there have been overreads or invalid values parsed) > > Thanks, > -- > Christophe > ___ > 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] doc/developer.texi: Add a code of conduct
Hi, 2016-05-20 2:38 GMT+02:00 Timothy Gu : >> > Note how it has a list of specific violations, instead of vague things like >> > "Be excellent" that the FFmpeg one has. >> > Note how it has a huge section on disciplinary procedures. [...] > I have to agree with Kieran here. I believe that as a community, we definitely > _want_ to assume good faith, etc. But conflict resolution requires strict, > codified consequences for violations of the CoC, to ensure fairness. The > language needs to be made more serious so that people actually take it in the > way it is intended. Completely agree. Without sanctions, I fear it won't help mitigate problems. Also I'd like this to extend to any medium: mailing list, irc, private communication between an offender and an "offended"... Secondly, I'd like this to apply to any comment, whether on a person or his work. Being frustrated is no reason for foul language, even if that's not the most hindering stuff that can happen. Also, because a text is subject to interpretation, the CoC could maybe state how this is arbitrated. Best regards, -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Vote] Code of Conduct
Hi, 2016-05-18 20:40 GMT+02:00 Michael Niedermayer : > Please state clearly if you agree to the text or if not. > we can extend and tune it later and do another vote if there are more > suggestions I agree to having a CoC. This text is a first step, so I'm ok with it, but hoping it will be improved. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit
On Fri, May 20, 2016 at 02:35:53PM +0200, Christophe Gisquet wrote: > 2016-05-13 11:48 GMT+02:00 foo86 : > > -unsigned int v = get_unary(gb, 1, 128); > > +unsigned int v = get_unary(gb, 1, get_bits_left(gb)); > > Not that the patch is not ok, but I have a few uneducated questions: > 1) Given the get_bits_long(gb, k) afterwards, won't that code cause > overreads for corrupted bitstreams? This will cause overread, but that should not be a problem for checked bitstream reader. > 2) I haven't checked the calling code, but consequently, wouldn't it > be better to first check that at least k+1 bits are available? I don't think this is necessarry. Fixed length overread is safe; adding explicit check will make code less readable IMO (and possibly slower). > 3) 128 is already fairly large; is the new code for valid bitstreams > (in the sense of specs and actually generated) or for corrupted > bitstreams? I don't know where the parsing is validated afterwards > (e.g. if there have been overreads or invalid values parsed) This is for valid bitstreams. There is no indication of limit on maximum Rice code length in the XLL spec, hence existing constant is not strictly "valid" (but it always worked in practice with existing encoders). Reference decoder also loops indefinitely until it sees stop bit here. Parsing is validated at the end of chs_parse_band_data(), there is an explicit check whether overread has occured (and if it has, entire segment is zeroed out). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS
Hi, 2016-05-20 1:55 GMT+02:00 Lukasz Marek : > Is Derek revoked to commit or what? Couldn't he just commit this patch and > leave? :P I was a problem for some people, but I see they still have > problems. Let people with problems go away with they problems. Sorry if you felt ganged up on previously. Hopefully the new Code of Conduct will avoid that such situations raise to an unsufferable level. But whatever bad technical blood there have been between the two of you, and whoever I may agree technically with, this is uncalled for. You're just adding fuel to a tense situation, and causing distress to someone. This type of comment is exactly what should not be allowed by the Code of Conduct. Sorry if I have added more fuel, -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit
Hi, 2016-05-20 15:09 GMT+02:00 foo86 : >> Not that the patch is not ok, but I have a few uneducated questions: >> 1) Given the get_bits_long(gb, k) afterwards, won't that code cause >> overreads for corrupted bitstreams? > > This will cause overread, but that should not be a problem for checked > bitstream reader. > >> 2) I haven't checked the calling code, but consequently, wouldn't it >> be better to first check that at least k+1 bits are available? > > I don't think this is necessarry. Fixed length overread is safe; adding > explicit check will make code less readable IMO (and possibly slower). I think the checked bitstream reader takes care of these. >> 3) 128 is already fairly large; is the new code for valid bitstreams >> (in the sense of specs and actually generated) or for corrupted >> bitstreams? I don't know where the parsing is validated afterwards >> (e.g. if there have been overreads or invalid values parsed) > > This is for valid bitstreams. There is no indication of limit on maximum > Rice code length in the XLL spec, hence existing constant is not > strictly "valid" (but it always worked in practice with existing > encoders). Reference decoder also loops indefinitely until it sees stop > bit here. OK. Out of curiosity, what are classical values there? "common" and max (128?). > Parsing is validated at the end of chs_parse_band_data(), there is an > explicit check whether overread has occured (and if it has, entire > segment is zeroed out). OK, so I think this patch is completely fine. Thanks, -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct
On Fri, May 20, 2016 at 02:50:17PM +0200, Christophe Gisquet wrote: > Hi, > > 2016-05-20 2:38 GMT+02:00 Timothy Gu : > >> > Note how it has a list of specific violations, instead of vague things > >> > like > >> > "Be excellent" that the FFmpeg one has. > >> > Note how it has a huge section on disciplinary procedures. > [...] > > I have to agree with Kieran here. I believe that as a community, we > > definitely > > _want_ to assume good faith, etc. But conflict resolution requires strict, > > codified consequences for violations of the CoC, to ensure fairness. The > > language needs to be made more serious so that people actually take it in > > the > > way it is intended. > > Completely agree. Without sanctions, I fear it won't help mitigate problems. I belive that people simply not accepting aggression and _politely_ pointing it out to their peers when they treat others disrespectful alone would already have a big effect on (i belive) debian lists i saw multiple people politely point out that an attack was inappropriate and it stoped, no one was banned I thus think similar stern but respectfull&polite community opposition alone could be effective for ffmpeg I think a big part of the problem is that if one insults another the friends of both support the seperation (that is we good vs. they bad thinking). People should instead oppose the disrespect itself but support people on both sides (we are all good, the language used / act there was bad) [...] > Also, because a text is subject to interpretation, the CoC could maybe > state how this is arbitrated. This is a very hard problem and also part of why i suggest to wait with adding penalties/sanctions. Note iam suggesting to wait with adding penalties NOT to not add penalties if it doesnt work without also if penalties are used they will in practice probably end up being applied to both sides as "who started" is likely often another very hard problem people would have very heated oppinions about [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit
On Fri, May 20, 2016 at 03:13:22PM +0200, Christophe Gisquet wrote: > > This is for valid bitstreams. There is no indication of limit on maximum > > Rice code length in the XLL spec, hence existing constant is not > > strictly "valid" (but it always worked in practice with existing > > encoders). Reference decoder also loops indefinitely until it sees stop > > bit here. > > OK. Out of curiosity, what are classical values there? "common" and max > (128?). Common values should be just a few bits. Maximum value seen in practice was 64, hence the limit 128 I've picked initially (before I realized get_unary(..., get_bits_left()) idiom is better). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Updated (v3) -- Add input mode autodetect to the decklink module.
bump
On 5/16/16, 9:28 AM, "ffmpeg-devel on behalf of Felt, Patrick"
wrote:
>bump
>
>On 5/12/16, 4:07 PM, "ffmpeg-devel on behalf of Felt, Patrick"
> wrote:
>
>>I hang my head in shame. I neglected to notice that time wasn’t already
>>included and so I had to modify the patch. Apologies for the noise.
>>
>>-- Add input mode autodetect to the decklink module. Previously users had to
>>supply the input format like this 'DeckLink Device@modenum'. This patch
>>allows users to either leave it off completely, or supply 0 or negative
>>number to indicate autodetect is requested. Autodetect only works the first
>>time so if the mode changes mid stream you'll die
>>
>>---
>> libavdevice/decklink_common.cpp | 110
>>
>> libavdevice/decklink_common.h | 5 ++
>> libavdevice/decklink_common_c.h | 1 +
>> libavdevice/decklink_dec.cpp| 86 +--
>> libavdevice/decklink_dec_c.c| 1 +
>> 5 files changed, 188 insertions(+), 15 deletions(-)
>>
>>diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
>>index ac7964c..1d51294 100644
>>--- a/libavdevice/decklink_common.cpp
>>+++ b/libavdevice/decklink_common.cpp
>>@@ -98,6 +98,90 @@ HRESULT ff_decklink_get_display_name(IDeckLink *This,
>>const char **displayName)
>> return hr;
>> }
>>
>>+long ff_decklink_mode_to_bm(AVFormatContext *avctx,
>>+ decklink_direction_t direction,
>>+ int ffmpeg_mode,
>>+ IDeckLinkDisplayMode **mode)
>>+{
>>+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
>>+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
>>+IDeckLinkDisplayModeIterator *itermode;
>>+IDeckLinkDisplayMode *internal_mode;
>>+
>>+int result=0;
>>+HRESULT res;
>>+
>>+if (direction == DIRECTION_IN) {
>>+res = ctx->dli->GetDisplayModeIterator (&itermode);
>>+} else {
>>+res = ctx->dlo->GetDisplayModeIterator (&itermode);
>>+}
>>+
>>+if (res != S_OK) {
>>+av_log(avctx, AV_LOG_ERROR, "Could not get the mode iterator\n");
>>+return -1;
>>+}
>>+
>>+while (itermode->Next(&internal_mode) == S_OK) {
>>+if (++result == ffmpeg_mode) {
>>+break;
>>+}
>>+
>>+internal_mode->Release();
>>+}
>>+
>>+itermode->Release();
>>+if (internal_mode) {
>>+result = internal_mode->GetDisplayMode();
>>+if (mode) {
>>+*mode = internal_mode;
>>+} else {
>>+internal_mode->Release();
>>+}
>>+
>>+return result;
>>+}
>>+
>>+return 0;
>>+}
>>+
>>+int ff_decklink_mode_to_ffmpeg(AVFormatContext *avctx,
>>+ decklink_direction_t direction,
>>+ IDeckLinkDisplayMode **mode)
>>+{
>>+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
>>+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
>>+IDeckLinkDisplayModeIterator *itermode;
>>+IDeckLinkDisplayMode *internal_mode;
>>+long bdm_mode_number = (*mode)->GetDisplayMode();
>>+int result=1, found=0;
>>+HRESULT res;
>>+
>>+if (direction == DIRECTION_IN) {
>>+res = ctx->dli->GetDisplayModeIterator (&itermode);
>>+} else {
>>+res = ctx->dlo->GetDisplayModeIterator (&itermode);
>>+}
>>+
>>+if (res != S_OK) {
>>+av_log(avctx, AV_LOG_ERROR, "Could not get the mode iterator\n");
>>+return -1;
>>+}
>>+
>>+while (itermode->Next(&internal_mode) == S_OK) {
>>+if (internal_mode->GetDisplayMode() == bdm_mode_number) {
>>+internal_mode->Release();
>>+found = 1;
>>+break;
>>+}
>>+internal_mode->Release();
>>+result++;
>>+}
>>+
>>+itermode->Release();
>>+return (found) ? result : -1;
>>+}
>>+
>> int ff_decklink_set_format(AVFormatContext *avctx,
>>int width, int height,
>>int tb_num, int tb_den,
>>@@ -197,6 +281,29 @@ int ff_decklink_list_devices(AVFormatContext *avctx)
>> return 0;
>> }
>>
>>+int ff_decklink_device_autodetect(AVFormatContext *avctx)
>>+{
>>+HRESULT res;
>>+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
>>+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
>>+IDeckLinkAttributes *attrs = NULL;
>>+bool auto_detect;
>>+
>>+res = ctx->dl->QueryInterface(IID_IDeckLinkAttributes, (void**)&attrs);
>>+if (res != S_OK) {
>>+av_log(avctx, AV_LOG_ERROR, "Could not get decklink attributes\n");
>>+return -1;
>>+}
>>+
>>+res = attrs->GetFlag(BMDDeckLinkSupportsInputFormatDetection,
>>&auto_detect);
>>+if (res != S_OK) {
>>+av_log(avctx, AV_LOG_ERROR, "Attribute fetch failed\n");
>>+return -1;
>>+}
>>+
>>+return (auto_detect)
Re: [FFmpeg-devel] [PATCH] Updated (v3) -- Add input mode autodetect to the decklink module.
bump
On 5/16/16, 9:28 AM, "ffmpeg-devel on behalf of Felt, Patrick"
wrote:
>bump
>
>On 5/12/16, 4:07 PM, "ffmpeg-devel on behalf of Felt, Patrick"
> wrote:
>
>>I hang my head in shame. I neglected to notice that time wasn’t already
>>included and so I had to modify the patch. Apologies for the noise.
>>
>>-- Add input mode autodetect to the decklink module. Previously users had to
>>supply the input format like this 'DeckLink Device@modenum'. This patch
>>allows users to either leave it off completely, or supply 0 or negative
>>number to indicate autodetect is requested. Autodetect only works the first
>>time so if the mode changes mid stream you'll die
>>
>>---
>> libavdevice/decklink_common.cpp | 110
>>
>> libavdevice/decklink_common.h | 5 ++
>> libavdevice/decklink_common_c.h | 1 +
>> libavdevice/decklink_dec.cpp| 86 +--
>> libavdevice/decklink_dec_c.c| 1 +
>> 5 files changed, 188 insertions(+), 15 deletions(-)
>>
>>diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
>>index ac7964c..1d51294 100644
>>--- a/libavdevice/decklink_common.cpp
>>+++ b/libavdevice/decklink_common.cpp
>>@@ -98,6 +98,90 @@ HRESULT ff_decklink_get_display_name(IDeckLink *This,
>>const char **displayName)
>> return hr;
>> }
>>
>>+long ff_decklink_mode_to_bm(AVFormatContext *avctx,
>>+ decklink_direction_t direction,
>>+ int ffmpeg_mode,
>>+ IDeckLinkDisplayMode **mode)
>>+{
>>+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
>>+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
>>+IDeckLinkDisplayModeIterator *itermode;
>>+IDeckLinkDisplayMode *internal_mode;
>>+
>>+int result=0;
>>+HRESULT res;
>>+
>>+if (direction == DIRECTION_IN) {
>>+res = ctx->dli->GetDisplayModeIterator (&itermode);
>>+} else {
>>+res = ctx->dlo->GetDisplayModeIterator (&itermode);
>>+}
>>+
>>+if (res != S_OK) {
>>+av_log(avctx, AV_LOG_ERROR, "Could not get the mode iterator\n");
>>+return -1;
>>+}
>>+
>>+while (itermode->Next(&internal_mode) == S_OK) {
>>+if (++result == ffmpeg_mode) {
>>+break;
>>+}
>>+
>>+internal_mode->Release();
>>+}
>>+
>>+itermode->Release();
>>+if (internal_mode) {
>>+result = internal_mode->GetDisplayMode();
>>+if (mode) {
>>+*mode = internal_mode;
>>+} else {
>>+internal_mode->Release();
>>+}
>>+
>>+return result;
>>+}
>>+
>>+return 0;
>>+}
>>+
>>+int ff_decklink_mode_to_ffmpeg(AVFormatContext *avctx,
>>+ decklink_direction_t direction,
>>+ IDeckLinkDisplayMode **mode)
>>+{
>>+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
>>+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
>>+IDeckLinkDisplayModeIterator *itermode;
>>+IDeckLinkDisplayMode *internal_mode;
>>+long bdm_mode_number = (*mode)->GetDisplayMode();
>>+int result=1, found=0;
>>+HRESULT res;
>>+
>>+if (direction == DIRECTION_IN) {
>>+res = ctx->dli->GetDisplayModeIterator (&itermode);
>>+} else {
>>+res = ctx->dlo->GetDisplayModeIterator (&itermode);
>>+}
>>+
>>+if (res != S_OK) {
>>+av_log(avctx, AV_LOG_ERROR, "Could not get the mode iterator\n");
>>+return -1;
>>+}
>>+
>>+while (itermode->Next(&internal_mode) == S_OK) {
>>+if (internal_mode->GetDisplayMode() == bdm_mode_number) {
>>+internal_mode->Release();
>>+found = 1;
>>+break;
>>+}
>>+internal_mode->Release();
>>+result++;
>>+}
>>+
>>+itermode->Release();
>>+return (found) ? result : -1;
>>+}
>>+
>> int ff_decklink_set_format(AVFormatContext *avctx,
>>int width, int height,
>>int tb_num, int tb_den,
>>@@ -197,6 +281,29 @@ int ff_decklink_list_devices(AVFormatContext *avctx)
>> return 0;
>> }
>>
>>+int ff_decklink_device_autodetect(AVFormatContext *avctx)
>>+{
>>+HRESULT res;
>>+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
>>+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
>>+IDeckLinkAttributes *attrs = NULL;
>>+bool auto_detect;
>>+
>>+res = ctx->dl->QueryInterface(IID_IDeckLinkAttributes, (void**)&attrs);
>>+if (res != S_OK) {
>>+av_log(avctx, AV_LOG_ERROR, "Could not get decklink attributes\n");
>>+return -1;
>>+}
>>+
>>+res = attrs->GetFlag(BMDDeckLinkSupportsInputFormatDetection,
>>&auto_detect);
>>+if (res != S_OK) {
>>+av_log(avctx, AV_LOG_ERROR, "Attribute fetch failed\n");
>>+return -1;
>>+}
>>+
>>+return (auto_detect)
Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct
Dana 20. 5. 2016. 15:21 osoba "Michael Niedermayer" napisala je: > > On Fri, May 20, 2016 at 02:50:17PM +0200, Christophe Gisquet wrote: > > Hi, > > > > 2016-05-20 2:38 GMT+02:00 Timothy Gu : > > >> > Note how it has a list of specific violations, instead of vague things like > > >> > "Be excellent" that the FFmpeg one has. > > >> > Note how it has a huge section on disciplinary procedures. > > [...] > > > I have to agree with Kieran here. I believe that as a community, we definitely > > > _want_ to assume good faith, etc. But conflict resolution requires strict, > > > codified consequences for violations of the CoC, to ensure fairness. The > > > language needs to be made more serious so that people actually take it in the > > > way it is intended. > > > > Completely agree. Without sanctions, I fear it won't help mitigate problems. > > I belive that people simply not accepting aggression and _politely_ > pointing it out to their peers when they treat others disrespectful > alone would already have a big effect > > on (i belive) debian lists i saw multiple people politely point out > that an attack was inappropriate and it stoped, no one was banned > I thus think similar stern but respectfull&polite community opposition > alone could be effective for ffmpeg > > I think a big part of the problem is that if one insults another > the friends of both support the seperation (that is we good vs. they > bad thinking). People should instead oppose the disrespect itself but > support people on both sides (we are all good, the language used / act > there was bad) Sorry, by you are simply wrong. This is about not following dev guide for patch submission and then attacking anyone, but that is less important now. Biggest problem is irrational thinking and spreading lies. > > [...] > > > > Also, because a text is subject to interpretation, the CoC could maybe > > state how this is arbitrated. > > This is a very hard problem and also part of why i suggest to wait > with adding penalties/sanctions. > Note iam suggesting to wait with adding penalties NOT to > not add penalties if it doesnt work without > > also if penalties are used they will in practice probably end up > being applied to both sides as "who started" is likely often another > very hard problem people would have very heated oppinions about > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Opposition brings concord. Out of discord comes the fairest harmony. > -- Heraclitus > > ___ > 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] FW: [PATCH] -- Add input swap functionality to movie filter(src_movie.c)
bump On 5/16/16, 2:15 PM, "ffmpeg-devel on behalf of Felt, Patrick" wrote: >This is a rework of the previously submitted patch to not require globals. >I’ve also renamed variables per standard. Attached is the output of git >format-patch (let me know if I should just paste contents into the body in the >future. This just felt a little cleaner). > > > swap-official-patch Description: swap-official-patch ___ 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] lavc/libopenh264enc: update to openh264 1.6
On 20 May 2016 at 11:37, Michael Niedermayer wrote: > as one testing ffmpeg with openh264 (building at least) > > i have mixed feelings about this, it would cause me to drop further > testing with openh264 in all releases OR in git master > because releases wont build with git master of openh264 and > master wont build with older openh264 > having 2 different versions installed would be possible but i will not > go to that troubble and i suspect noone else will either I see very few distros actually packaging OpenH264 (it's mainly only used by Firefox, but there's a GStreamer plugin for it too, I think), but when they do it's either 1.5 (Archlinux AUR) or 1.5.3 (Fedora 23-25). Not using Cisco's binaries voids the patent protection, so I guess that's why they don't package it. Depends on whether FFmpeg cares about supporting non-releases. If it doesn't it should probably be noted somewhere, at least in the wiki. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/avf_ahistogram: raise minimum acmax to 1
If acmax can be 0 then it could result in a division by 0
Fixes CID1351345
Signed-off-by: Michael Niedermayer
---
libavfilter/avf_ahistogram.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/avf_ahistogram.c b/libavfilter/avf_ahistogram.c
index a716a96..ff94ad4 100644
--- a/libavfilter/avf_ahistogram.c
+++ b/libavfilter/avf_ahistogram.c
@@ -165,7 +165,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
const int H = s->histogram_h;
const int w = s->w;
int c, y, n, p, bin;
-uint64_t acmax = 0;
+uint64_t acmax = 1;
if (!s->out || s->out->width != outlink->w ||
s->out->height != outlink->h) {
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Build fix for openh264 1.6.0
Added more options for OpenH264 encoder
---
libavcodec/libopenh264enc.c | 60 +
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 24bc228..532cb5d 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -36,9 +36,11 @@ typedef struct SVCContext {
const AVClass *av_class;
ISVCEncoder *encoder;
int slice_mode;
+int rc_mode;
int loopfilter;
char *profile;
int max_nal_size;
+int slice_mbs;
int skip_frames;
int skipped;
int cabac;
@@ -51,16 +53,25 @@ typedef struct SVCContext {
#define OFFSET(x) offsetof(SVCContext, x)
#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
-{ "slice_mode", "set slice mode", OFFSET(slice_mode), AV_OPT_TYPE_INT, {
.i64 = SM_AUTO_SLICE }, SM_SINGLE_SLICE, SM_RESERVED, VE, "slice_mode" },
+{ "slice_mode", "set slice mode", OFFSET(slice_mode), AV_OPT_TYPE_INT, {
.i64 = SM_SINGLE_SLICE }, SM_SINGLE_SLICE, SM_RESERVED, VE, "slice_mode" },
+{ "single", "single slice per frame", 0, AV_OPT_TYPE_CONST, { .i64 =
SM_SINGLE_SLICE }, 0, 0, VE, "slice_mode" },
{ "fixed", "a fixed number of slices", 0, AV_OPT_TYPE_CONST, { .i64 =
SM_FIXEDSLCNUM_SLICE }, 0, 0, VE, "slice_mode" },
-{ "rowmb", "one slice per row of macroblocks", 0, AV_OPT_TYPE_CONST, {
.i64 = SM_ROWMB_SLICE }, 0, 0, VE, "slice_mode" },
-{ "auto", "automatic number of slices according to number of threads",
0, AV_OPT_TYPE_CONST, { .i64 = SM_AUTO_SLICE }, 0, 0, VE, "slice_mode" },
-{ "dyn", "Dynamic slicing", 0, AV_OPT_TYPE_CONST, { .i64 =
SM_DYN_SLICE }, 0, 0, VE, "slice_mode" },
+{ "raster", "slicing acording to macroblock numbers per each slice",
0, AV_OPT_TYPE_CONST, { .i64 = SM_RASTER_SLICE }, 0, 0, VE, "slice_mode" },
+{ "sizelimited", "slicing according to slice size", 0,
AV_OPT_TYPE_CONST, { .i64 = SM_SIZELIMITED_SLICE }, 0, 0, VE, "slice_mode" },
+{ "rc_mode", "set rate controle mode", OFFSET(rc_mode), AV_OPT_TYPE_INT, {
.i64 = RC_QUALITY_MODE }, RC_OFF_MODE, RC_BITRATE_MODE_POST_SKIP, VE, "rc_mode"
},
+{ "quality", "quality-based mode", 0, AV_OPT_TYPE_CONST, { .i64 =
RC_QUALITY_MODE }, 0, 0, VE, "rc_mode" },
+{ "bitrate", "bitrate-based mode", 0, AV_OPT_TYPE_CONST, { .i64 =
RC_BITRATE_MODE }, 0, 0, VE, "rc_mode" },
+{ "bufferbased" , "using buffer status to adjust bitrate", 0,
AV_OPT_TYPE_CONST, { .i64 = RC_BUFFERBASED_MODE }, 0, 0, VE, "rc_mode" },
+{ "timestamp", "using timestamp to adjust bitrate", 0,
AV_OPT_TYPE_CONST, { .i64 = RC_TIMESTAMP_MODE }, 0, 0, VE, "rc_mode" },
+{ "off", "no bitrate control", 0, AV_OPT_TYPE_CONST, { .i64 =
RC_OFF_MODE }, 0, 0, VE, "rc_mode" },
{ "loopfilter", "enable loop filter", OFFSET(loopfilter), AV_OPT_TYPE_INT,
{ .i64 = 1 }, 0, 1, VE },
{ "profile", "set profile restrictions", OFFSET(profile),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VE },
-{ "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
+{ "max_nal_size", "set maximum slice size in bytes", OFFSET(max_nal_size),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
+{ "slice_mbs", "set number of macroblocks per size", OFFSET(slice_mbs),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
{ "allow_skip_frames", "allow skipping frames to hit the target bitrate",
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
-{ "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 },
0, 1, VE },
+{ "entropy", "set entropy encoding mode", OFFSET(cabac), AV_OPT_TYPE_BOOL,
{ .i64 = 0 }, 0, 1, VE, "entropy_mode" },
+{ "cabac", "use CABAC", 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, 0, 0, VE,
"entropy_mode" },
+{ "cavlc", "use CAVLC", 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 0, VE,
"entropy_mode" },
{ NULL }
};
@@ -154,7 +165,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
param.iPicHeight = avctx->height;
param.iTargetBitrate = avctx->bit_rate;
param.iMaxBitrate= FFMAX(avctx->rc_max_rate,
avctx->bit_rate);
-param.iRCMode= RC_QUALITY_MODE;
+param.iRCMode= s->rc_mode;
param.iTemporalLayerNum = 1;
param.iSpatialLayerNum = 1;
param.bEnableDenoise = 0;
@@ -172,11 +183,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
param.bPrefixNalAddingCtrl = 0;
param.iLoopFilterDisableIdc = !s->loopfilter;
param.iEntropyCodingModeFlag = 0;
-param.iMultipleThreadIdc = avctx->thread_count;
if (s->profile && !strcmp(s->profile, "main"))
param.iEntropyCodingModeFlag = 1;
else if (!s->profile && s->cabac)
param.iEntropyCodingModeFlag = 1;
+param.iMultipleThreadI
Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit
On 5/20/2016 10:13 AM, Christophe Gisquet wrote: > Hi, > > 2016-05-20 15:09 GMT+02:00 foo86 : > >>> Not that the patch is not ok, but I have a few uneducated questions: >>> 1) Given the get_bits_long(gb, k) afterwards, won't that code cause >>> overreads for corrupted bitstreams? >> >> This will cause overread, but that should not be a problem for checked >> bitstream reader. >> >>> 2) I haven't checked the calling code, but consequently, wouldn't it >>> be better to first check that at least k+1 bits are available? >> >> I don't think this is necessarry. Fixed length overread is safe; adding >> explicit check will make code less readable IMO (and possibly slower). > > I think the checked bitstream reader takes care of these. > >>> 3) 128 is already fairly large; is the new code for valid bitstreams >>> (in the sense of specs and actually generated) or for corrupted >>> bitstreams? I don't know where the parsing is validated afterwards >>> (e.g. if there have been overreads or invalid values parsed) >> >> This is for valid bitstreams. There is no indication of limit on maximum >> Rice code length in the XLL spec, hence existing constant is not >> strictly "valid" (but it always worked in practice with existing >> encoders). Reference decoder also loops indefinitely until it sees stop >> bit here. > > OK. Out of curiosity, what are classical values there? "common" and max > (128?). > >> Parsing is validated at the end of chs_parse_band_data(), there is an >> explicit check whether overread has occured (and if it has, entire >> segment is zeroed out). > > OK, so I think this patch is completely fine. > > Thanks, Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/10] avcodec/dca_parser: improve frame end search
On Fri, May 13, 2016 at 12:48:28PM +0300, foo86 wrote: > Parse core frame size directly when searching for frame end instead of > using value extracted from previous frame. > > Account for unused bits when calculating sync word distance for 14-bit > streams to avoid alias sync detection. > > Parse EXSS frame size and skip over EXSS frame to avoid alias sync > detection. > --- > libavcodec/dca_parser.c | 94 > + > 1 file changed, 80 insertions(+), 14 deletions(-) Fixes parser failure with the following sample: https://0x0.st/q4G.dts ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 10/10] avcodec/dca: remove useless debug message
On 5/13/2016 6:48 AM, foo86 wrote:
> Most DTS-in-WAV streams trigger this, making debug output hard to read.
> ---
> libavcodec/dca_core.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
> index f6c22ca..46825ed 100644
> --- a/libavcodec/dca_core.c
> +++ b/libavcodec/dca_core.c
> @@ -1921,10 +1921,8 @@ int ff_dca_core_parse(DCACoreDecoder *s, uint8_t
> *data, int size)
> return ret;
>
> // Workaround for DTS in WAV
> -if (s->frame_size > size && s->frame_size < size + 4) {
> -av_log(s->avctx, AV_LOG_DEBUG, "Working around excessive core frame
> size (%d > %d)\n", s->frame_size, size);
> +if (s->frame_size > size && s->frame_size < size + 4)
> s->frame_size = size;
> -}
>
> if (ff_dca_seek_bits(&s->gb, s->frame_size * 8)) {
> av_log(s->avctx, AV_LOG_ERROR, "Read past end of core frame\n");
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_ahistogram: raise minimum acmax to 1
On 5/20/16, Michael Niedermayer wrote:
> If acmax can be 0 then it could result in a division by 0
> Fixes CID1351345
But there is cast to double.
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/avf_ahistogram.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/avf_ahistogram.c b/libavfilter/avf_ahistogram.c
> index a716a96..ff94ad4 100644
> --- a/libavfilter/avf_ahistogram.c
> +++ b/libavfilter/avf_ahistogram.c
> @@ -165,7 +165,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> const int H = s->histogram_h;
> const int w = s->w;
> int c, y, n, p, bin;
> -uint64_t acmax = 0;
> +uint64_t acmax = 1;
>
> if (!s->out || s->out->width != outlink->w ||
> s->out->height != outlink->h) {
> --
> 1.7.9.5
>
> ___
> 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 04/10] avcodec/dca: don't set initial sample_fmt
On 5/14/2016 3:08 PM, Michael Niedermayer wrote: > On Sat, May 14, 2016 at 06:48:51PM +0300, foo86 wrote: >> On Fri, May 13, 2016 at 12:00:24PM +0200, Hendrik Leppkes wrote: >>> On Fri, May 13, 2016 at 11:48 AM, foo86 wrote: Valid sample_fmt will be set by dcadec_decode_frame() based on stream type. --- libavcodec/dcadec.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c index e3a4b0d..565242d 100644 --- a/libavcodec/dcadec.c +++ b/libavcodec/dcadec.c @@ -374,9 +374,6 @@ static av_cold int dcadec_init(AVCodecContext *avctx) break; } -avctx->sample_fmt = AV_SAMPLE_FMT_S32P; -avctx->bits_per_raw_sample = 24; - return 0; } >>> >>> Having an initial format for the most "common" types of streams is >>> generally sensible. >> >> Do you suggest it should be changed to AV_SAMPLE_FMT_FLTP then? Core >> streams are probably the most "common". >> > >> I don't have a strong prefenence on this, but I thought that not having >> initial sample_fmt set will serve as useful indication to API user that >> sample_fmt can (and will) change after the frame is decoded. > > i feel similarly ... Pushed then. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Masked LZ Decompression
Hi, I'm working on implementing floating point support in the ALS decoder. In this I've to use masked LZ decompression. I've written the code for myself for masked lz decompression using the help from the reference software. Although, I'm not yet sure if an implementation of masked LZ is already there in FFmpeg or not. If it is already there, it makes no sense to have my own implementation as well. So anybody has any idea if we have masked LZ implementation already or not ? Thanks, Umair ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Masked LZ Decompression
On 5/20/16, Umair Khan wrote: > Hi, > > I'm working on implementing floating point support in the ALS decoder. > In this I've to use masked LZ decompression. I've written the code for > myself for masked lz decompression using the help from the reference > software. > Although, I'm not yet sure if an implementation of masked LZ is > already there in FFmpeg or not. > If it is already there, it makes no sense to have my own implementation as > well. > > So anybody has any idea if we have masked LZ implementation already or not ? IMHO we do not. Because its audio related. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/aic: add frame threading support
Hi,
patch attached.
From 36ea9fd3b3611d1946e3dd3f384b638fa079291e Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 20 May 2016 20:54:10 +0200
Subject: [PATCH] avcodec/aic: add frame threading support
Signed-off-by: Paul B Mahol
---
libavcodec/aic.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aic.c b/libavcodec/aic.c
index 5decc78..ff8e392 100644
--- a/libavcodec/aic.c
+++ b/libavcodec/aic.c
@@ -28,6 +28,7 @@
#include "get_bits.h"
#include "golomb.h"
#include "idctdsp.h"
+#include "thread.h"
#include "unary.h"
#define AIC_HDR_SIZE24
@@ -375,6 +376,7 @@ static int aic_decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
uint32_t off;
int x, y, ret;
int slice_size;
+ThreadFrame frame = { .f = data };
ctx->frame= data;
ctx->frame->pict_type = AV_PICTURE_TYPE_I;
@@ -393,7 +395,7 @@ static int aic_decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
return ret;
}
-if ((ret = ff_get_buffer(avctx, ctx->frame, 0)) < 0)
+if ((ret = ff_thread_get_buffer(avctx, &frame, 0)) < 0)
return ret;
bytestream2_init(&gb, buf + AIC_HDR_SIZE,
@@ -488,5 +490,6 @@ AVCodec ff_aic_decoder = {
.init = aic_decode_init,
.close = aic_decode_close,
.decode = aic_decode_frame,
-.capabilities = AV_CODEC_CAP_DR1,
+.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
+.init_thread_copy = ONLY_IF_THREADS_ENABLED(aic_decode_init),
};
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/sgirledec: simplify, no need to use reget buffer
Hi,
patch attached.
From da5353cd2d54de387bb1617c4fc58f919053bc43 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 20 May 2016 21:30:29 +0200
Subject: [PATCH] avcodec/sgirledec: simplify, no need to use reget buffer
Signed-off-by: Paul B Mahol
---
libavcodec/sgirledec.c | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/libavcodec/sgirledec.c b/libavcodec/sgirledec.c
index e7b281a..aa4f0e7 100644
--- a/libavcodec/sgirledec.c
+++ b/libavcodec/sgirledec.c
@@ -31,17 +31,9 @@
#include "avcodec.h"
#include "internal.h"
-typedef struct SGIRLEContext {
-AVFrame *frame;
-} SGIRLEContext;
-
static av_cold int sgirle_decode_init(AVCodecContext *avctx)
{
-SGIRLEContext *s = avctx->priv_data;
avctx->pix_fmt = AV_PIX_FMT_BGR8;
-s->frame = av_frame_alloc();
-if (!s->frame)
-return AVERROR(ENOMEM);
return 0;
}
@@ -120,41 +112,31 @@ static int decode_sgirle8(AVCodecContext *avctx, uint8_t *dst,
static int sgirle_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame, AVPacket *avpkt)
{
-SGIRLEContext *s = avctx->priv_data;
+AVFrame *frame = data;
int ret;
-if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
return ret;
-ret = decode_sgirle8(avctx, s->frame->data[0], avpkt->data, avpkt->size,
- avctx->width, avctx->height, s->frame->linesize[0]);
+ret = decode_sgirle8(avctx, frame->data[0], avpkt->data, avpkt->size,
+ avctx->width, avctx->height, frame->linesize[0]);
if (ret < 0)
return ret;
+frame->pict_type = AV_PICTURE_TYPE_I;
+frame->key_frame = 1;
+
*got_frame = 1;
-if ((ret = av_frame_ref(data, s->frame)) < 0)
-return ret;
return avpkt->size;
}
-static av_cold int sgirle_decode_end(AVCodecContext *avctx)
-{
-SGIRLEContext *s = avctx->priv_data;
-
-av_frame_free(&s->frame);
-
-return 0;
-}
-
AVCodec ff_sgirle_decoder = {
.name = "sgirle",
.long_name = NULL_IF_CONFIG_SMALL("Silicon Graphics RLE 8-bit video"),
.type = AVMEDIA_TYPE_VIDEO,
.id = AV_CODEC_ID_SGIRLE,
-.priv_data_size = sizeof(SGIRLEContext),
.init = sgirle_decode_init,
-.close = sgirle_decode_end,
.decode = sgirle_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
};
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/10] avcodec/dca_parser: improve frame end search
On 5/20/2016 2:40 PM, foo86 wrote: > On Fri, May 13, 2016 at 12:48:28PM +0300, foo86 wrote: >> Parse core frame size directly when searching for frame end instead of >> using value extracted from previous frame. >> >> Account for unused bits when calculating sync word distance for 14-bit >> streams to avoid alias sync detection. >> >> Parse EXSS frame size and skip over EXSS frame to avoid alias sync >> detection. >> --- >> libavcodec/dca_parser.c | 94 >> + >> 1 file changed, 80 insertions(+), 14 deletions(-) > > Fixes parser failure with the following sample: https://0x0.st/q4G.dts Seems to happen with codec copy only, two frames were being treated as one. Decoding doesn't seem affected by this patch. framecrc output looks the same before and after. Applied, thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] libavcodec/nvenc.c: split large functions into smaller ones
Functions names and scopes are from libav. This commit basically moves
code around without changing it; it shouldn't change any functionality
except some small leak fixes on error paths.
---
libavcodec/nvenc.c | 1083 ++--
1 file changed, 622 insertions(+), 461 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 104aea0..3d53a0f 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -541,44 +541,17 @@ static av_cold void nvenc_unload_nvenc(AVCodecContext *avctx)
av_log(avctx, AV_LOG_VERBOSE, "Nvenc unloaded\n");
}
-static av_cold int nvenc_encode_init(AVCodecContext *avctx)
+static av_cold int nvenc_setup_device(AVCodecContext *avctx)
{
-NV_ENC_OPEN_ENCODE_SESSION_EX_PARAMS encode_session_params = { 0 };
-NV_ENC_PRESET_CONFIG preset_config = { 0 };
-CUcontext cu_context_curr;
-CUresult cu_res;
-GUID encoder_preset = NV_ENC_PRESET_HQ_GUID;
-GUID codec;
-NVENCSTATUS nv_status = NV_ENC_SUCCESS;
-AVCPBProperties *cpb_props;
-int surfaceCount = 0;
-int i, num_mbs;
-int isLL = 0;
-int lossless = 0;
-int res = 0;
-int dw, dh;
-int qp_inter_p;
-
NvencContext *ctx = avctx->priv_data;
NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
-NV_ENCODE_API_FUNCTION_LIST *p_nvenc = &dl_fn->nvenc_funcs;
-if (!nvenc_dyload_nvenc(avctx))
-return AVERROR_EXTERNAL;
-
-ctx->last_dts = AV_NOPTS_VALUE;
-
-ctx->encode_config.version = NV_ENC_CONFIG_VER;
-ctx->init_encode_params.version = NV_ENC_INITIALIZE_PARAMS_VER;
-preset_config.version = NV_ENC_PRESET_CONFIG_VER;
-preset_config.presetCfg.version = NV_ENC_CONFIG_VER;
-encode_session_params.version = NV_ENC_OPEN_ENCODE_SESSION_EX_PARAMS_VER;
-encode_session_params.apiVersion = NVENCAPI_VERSION;
+CUresult cu_res;
+CUcontext cu_context_curr;
if (ctx->gpu >= dl_fn->nvenc_device_count) {
av_log(avctx, AV_LOG_FATAL, "Requested GPU %d, but only %d GPUs are available!\n", ctx->gpu, dl_fn->nvenc_device_count);
-res = AVERROR(EINVAL);
-goto error;
+return AVERROR(EINVAL);
}
ctx->cu_context = NULL;
@@ -586,18 +559,30 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
if (cu_res != CUDA_SUCCESS) {
av_log(avctx, AV_LOG_FATAL, "Failed creating CUDA context for NVENC: 0x%x\n", (int)cu_res);
-res = AVERROR_EXTERNAL;
-goto error;
+return AVERROR_EXTERNAL;
}
cu_res = dl_fn->cu_ctx_pop_current(&cu_context_curr);
if (cu_res != CUDA_SUCCESS) {
av_log(avctx, AV_LOG_FATAL, "Failed popping CUDA context: 0x%x\n", (int)cu_res);
-res = AVERROR_EXTERNAL;
-goto error;
+return AVERROR_EXTERNAL;
}
+return 0;
+}
+
+static av_cold int nvenc_open_session(AVCodecContext *avctx)
+{
+NvencContext *ctx = avctx->priv_data;
+NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
+NV_ENCODE_API_FUNCTION_LIST *p_nvenc = &dl_fn->nvenc_funcs;
+
+NV_ENC_OPEN_ENCODE_SESSION_EX_PARAMS encode_session_params = { 0 };
+NVENCSTATUS nv_status;
+
+encode_session_params.version = NV_ENC_OPEN_ENCODE_SESSION_EX_PARAMS_VER;
+encode_session_params.apiVersion = NVENCAPI_VERSION;
encode_session_params.device = ctx->cu_context;
encode_session_params.deviceType = NV_ENC_DEVICE_TYPE_CUDA;
@@ -605,10 +590,322 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
if (nv_status != NV_ENC_SUCCESS) {
ctx->nvencoder = NULL;
av_log(avctx, AV_LOG_FATAL, "OpenEncodeSessionEx failed: 0x%x\n", (int)nv_status);
-res = AVERROR_EXTERNAL;
-goto error;
+return AVERROR_EXTERNAL;
+}
+
+return 0;
+}
+
+static av_cold void set_constqp(AVCodecContext *avctx)
+{
+NvencContext *ctx = avctx->priv_data;
+
+ctx->encode_config.rcParams.rateControlMode = NV_ENC_PARAMS_RC_CONSTQP;
+ctx->encode_config.rcParams.constQP.qpInterB = avctx->global_quality;
+ctx->encode_config.rcParams.constQP.qpInterP = avctx->global_quality;
+ctx->encode_config.rcParams.constQP.qpIntra = avctx->global_quality;
+}
+
+static av_cold void set_vbr(AVCodecContext *avctx)
+{
+NvencContext *ctx = avctx->priv_data;
+
+ctx->encode_config.rcParams.enableMinQP = 1;
+ctx->encode_config.rcParams.enableMaxQP = 1;
+
+ctx->encode_config.rcParams.minQP.qpInterB = avctx->qmin;
+ctx->encode_config.rcParams.minQP.qpInterP = avctx->qmin;
+ctx->encode_config.rcParams.minQP.qpIntra = avctx->qmin;
+
+ctx->encode_config.rcParams.maxQP.qpInterB = avctx->qmax;
+ctx->encode_config.rcParams.maxQP.qpInterP = avctx->qmax;
+ctx->encode_config.rcParams.maxQP.qpIntra = avctx->qmax;
+}
+
+static av_cold void set_lossless(AVCodecContext *avctx)
+{
+NvencContext *ctx = avctx->priv_data;
+
+ctx->encode_config.rcParams.rateControlMode = NV_ENC_PARAMS_RC_CONSTQP;
+ctx->encode_config.rcPa
[FFmpeg-devel] [PATCH 2/4] libavcodec/nvenc.c: combine input and output surface structures
There is no point in separate structures as they have 1:1 relationship,
they are always used together and they have same lifetime.
---
libavcodec/nvenc.c | 196 -
1 file changed, 105 insertions(+), 91 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 3d53a0f..19312dc 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -67,7 +67,7 @@ typedef CUresult(CUDAAPI *PCUCTXDESTROY)(CUcontext ctx);
typedef NVENCSTATUS (NVENCAPI* PNVENCODEAPICREATEINSTANCE)(NV_ENCODE_API_FUNCTION_LIST *functionList);
-typedef struct NvencInputSurface
+typedef struct NvencSurface
{
NV_ENC_INPUT_PTR input_surface;
int width;
@@ -76,23 +76,16 @@ typedef struct NvencInputSurface
int lockCount;
NV_ENC_BUFFER_FORMAT format;
-} NvencInputSurface;
-typedef struct NvencOutputSurface
-{
NV_ENC_OUTPUT_PTR output_surface;
int size;
-
-NvencInputSurface* input_surface;
-
-int busy;
-} NvencOutputSurface;
+} NvencSurface;
typedef struct NvencData
{
union {
int64_t timestamp;
-NvencOutputSurface *surface;
+NvencSurface *surface;
} u;
} NvencData;
@@ -146,8 +139,7 @@ typedef struct NvencContext
CUcontext cu_context;
int max_surface_count;
-NvencInputSurface *input_surfaces;
-NvencOutputSurface *output_surfaces;
+NvencSurface *surfaces;
NvencDataList output_surface_queue;
NvencDataList output_surface_ready_queue;
@@ -217,6 +209,64 @@ static const NvencValuePair nvenc_hevc_level_pairs[] = {
{ NULL }
};
+static const struct {
+NVENCSTATUS nverr;
+int averr;
+const char *desc;
+} nvenc_errors[] = {
+{ NV_ENC_SUCCESS, 0,"success" },
+{ NV_ENC_ERR_NO_ENCODE_DEVICE, AVERROR(ENOENT), "no encode device" },
+{ NV_ENC_ERR_UNSUPPORTED_DEVICE, AVERROR(ENOSYS), "unsupported device" },
+{ NV_ENC_ERR_INVALID_ENCODERDEVICE,AVERROR(EINVAL), "invalid encoder device" },
+{ NV_ENC_ERR_INVALID_DEVICE, AVERROR(EINVAL), "invalid device" },
+{ NV_ENC_ERR_DEVICE_NOT_EXIST, AVERROR(EIO), "device does not exist"},
+{ NV_ENC_ERR_INVALID_PTR, AVERROR(EFAULT), "invalid ptr" },
+{ NV_ENC_ERR_INVALID_EVENT,AVERROR(EINVAL), "invalid event"},
+{ NV_ENC_ERR_INVALID_PARAM,AVERROR(EINVAL), "invalid param"},
+{ NV_ENC_ERR_INVALID_CALL, AVERROR(EINVAL), "invalid call" },
+{ NV_ENC_ERR_OUT_OF_MEMORY,AVERROR(ENOMEM), "out of memory"},
+{ NV_ENC_ERR_ENCODER_NOT_INITIALIZED, AVERROR(EINVAL), "encoder not initialized" },
+{ NV_ENC_ERR_UNSUPPORTED_PARAM,AVERROR(ENOSYS), "unsupported param"},
+{ NV_ENC_ERR_LOCK_BUSY,AVERROR(EAGAIN), "lock busy"},
+{ NV_ENC_ERR_NOT_ENOUGH_BUFFER,AVERROR(ENOBUFS), "not enough buffer"},
+{ NV_ENC_ERR_INVALID_VERSION, AVERROR(EINVAL), "invalid version" },
+{ NV_ENC_ERR_MAP_FAILED, AVERROR(EIO), "map failed" },
+{ NV_ENC_ERR_NEED_MORE_INPUT, AVERROR(EAGAIN), "need more input" },
+{ NV_ENC_ERR_ENCODER_BUSY, AVERROR(EAGAIN), "encoder busy" },
+{ NV_ENC_ERR_EVENT_NOT_REGISTERD, AVERROR(EBADF), "event not registered" },
+{ NV_ENC_ERR_GENERIC, AVERROR_UNKNOWN, "generic error"},
+{ NV_ENC_ERR_INCOMPATIBLE_CLIENT_KEY, AVERROR(EINVAL), "incompatible client key" },
+{ NV_ENC_ERR_UNIMPLEMENTED,AVERROR(ENOSYS), "unimplemented"},
+{ NV_ENC_ERR_RESOURCE_REGISTER_FAILED, AVERROR(EIO), "resource register failed" },
+{ NV_ENC_ERR_RESOURCE_NOT_REGISTERED, AVERROR(EBADF), "resource not registered" },
+{ NV_ENC_ERR_RESOURCE_NOT_MAPPED, AVERROR(EBADF), "resource not mapped" },
+};
+
+static int nvenc_map_error(NVENCSTATUS err, const char **desc)
+{
+int i;
+for (i = 0; i < FF_ARRAY_ELEMS(nvenc_errors); i++) {
+if (nvenc_errors[i].nverr == err) {
+if (desc)
+*desc = nvenc_errors[i].desc;
+return nvenc_errors[i].averr;
+}
+}
+if (desc)
+*desc = "unknown error";
+return AVERROR_UNKNOWN;
+}
+
+static int nvenc_print_error(void *log_ctx, NVENCSTATUS err,
+ const char *error_string)
+{
+const char *desc;
+int ret;
+ret = nvenc_map_error(err, &desc);
+av_log(log_ctx, AV_LOG_ERROR, "%s: %s (%d)\n", error_string, desc, err);
+return ret;
+}
+
static int input_string_to_uint32(AVCodecContext *avctx, const NvencValuePair *pair, const char *input, uint32_t *output)
{
for (; pair->str; ++pair) {
@@ -294,7 +344,7 @@ stati
[FFmpeg-devel] [PATCH 3/4] libavcodec/nvenc.c: replace custom FIFOs with AVFifos
---
libavcodec/nvenc.c | 187 ++---
1 file changed, 50 insertions(+), 137 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 19312dc..d3856a4 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -27,6 +27,7 @@
#include
+#include "libavutil/fifo.h"
#include "libavutil/internal.h"
#include "libavutil/imgutils.h"
#include "libavutil/avassert.h"
@@ -89,15 +90,6 @@ typedef struct NvencData
} u;
} NvencData;
-typedef struct NvencDataList
-{
-NvencData* data;
-
-uint32_t pos;
-uint32_t count;
-uint32_t size;
-} NvencDataList;
-
typedef struct NvencDynLoadFunctions
{
PCUINIT cu_init;
@@ -141,9 +133,9 @@ typedef struct NvencContext
int max_surface_count;
NvencSurface *surfaces;
-NvencDataList output_surface_queue;
-NvencDataList output_surface_ready_queue;
-NvencDataList timestamp_list;
+AVFifoBuffer *output_surface_queue;
+AVFifoBuffer *output_surface_ready_queue;
+AVFifoBuffer *timestamp_list;
int64_t last_dts;
void *nvencoder;
@@ -279,105 +271,18 @@ static int input_string_to_uint32(AVCodecContext *avctx, const NvencValuePair *p
return AVERROR(EINVAL);
}
-static NvencData* data_queue_dequeue(NvencDataList* queue)
-{
-uint32_t mask;
-uint32_t read_pos;
-
-av_assert0(queue);
-av_assert0(queue->size);
-av_assert0(queue->data);
-
-if (!queue->count)
-return NULL;
-
-/* Size always is a multiple of two */
-mask = queue->size - 1;
-read_pos = (queue->pos - queue->count) & mask;
-queue->count--;
-
-return &queue->data[read_pos];
-}
-
-static int data_queue_enqueue(NvencDataList* queue, NvencData *data)
-{
-NvencDataList new_queue;
-NvencData* tmp_data;
-uint32_t mask;
-
-if (!queue->size) {
-/* size always has to be a multiple of two */
-queue->size = 4;
-queue->pos = 0;
-queue->count = 0;
-
-queue->data = av_malloc(queue->size * sizeof(*(queue->data)));
-
-if (!queue->data) {
-queue->size = 0;
-return AVERROR(ENOMEM);
-}
-}
-
-if (queue->count == queue->size) {
-new_queue.size = queue->size << 1;
-new_queue.pos = 0;
-new_queue.count = 0;
-new_queue.data = av_malloc(new_queue.size * sizeof(*(queue->data)));
-
-if (!new_queue.data)
-return AVERROR(ENOMEM);
-
-while (tmp_data = data_queue_dequeue(queue))
-data_queue_enqueue(&new_queue, tmp_data);
-
-av_free(queue->data);
-*queue = new_queue;
-}
-
-mask = queue->size - 1;
-
-queue->data[queue->pos] = *data;
-queue->pos = (queue->pos + 1) & mask;
-queue->count++;
-
-return 0;
-}
-
-static int out_surf_queue_enqueue(NvencDataList* queue, NvencSurface* surface)
-{
-NvencData data;
-data.u.surface = surface;
-
-return data_queue_enqueue(queue, &data);
-}
-
-static NvencSurface* out_surf_queue_dequeue(NvencDataList* queue)
+static void timestamp_queue_enqueue(AVFifoBuffer* queue, int64_t timestamp)
{
-NvencData* res = data_queue_dequeue(queue);
-
-if (!res)
-return NULL;
-
-return res->u.surface;
+av_fifo_generic_write(queue, ×tamp, sizeof(timestamp), NULL);
}
-static int timestamp_queue_enqueue(NvencDataList* queue, int64_t timestamp)
+static int64_t timestamp_queue_dequeue(AVFifoBuffer* queue)
{
-NvencData data;
-data.u.timestamp = timestamp;
+int64_t timestamp = AV_NOPTS_VALUE;
+if (av_fifo_size(queue) > 0)
+av_fifo_generic_read(queue, ×tamp, sizeof(timestamp), NULL);
-return data_queue_enqueue(queue, &data);
-}
-
-static int64_t timestamp_queue_dequeue(NvencDataList* queue)
-{
-NvencData* res = data_queue_dequeue(queue);
-
-if (!res)
-return AV_NOPTS_VALUE;
-
-return res->u.timestamp;
+return timestamp;
}
#define CHECK_LOAD_FUNC(t, f, s) \
@@ -1218,6 +1123,16 @@ static av_cold int nvenc_setup_surfaces(AVCodecContext *avctx, int* surfaceCount
return AVERROR(ENOMEM);
}
+ctx->timestamp_list = av_fifo_alloc(ctx->max_surface_count * sizeof(int64_t));
+if (!ctx->timestamp_list)
+return AVERROR(ENOMEM);
+ctx->output_surface_queue = av_fifo_alloc(ctx->max_surface_count * sizeof(NvencSurface*));
+if (!ctx->output_surface_queue)
+return AVERROR(ENOMEM);
+ctx->output_surface_ready_queue = av_fifo_alloc(ctx->max_surface_count * sizeof(NvencSurface*));
+if (!ctx->output_surface_ready_queue)
+return AVERROR(ENOMEM);
+
for(*surfaceCount = 0; *surfaceCount < ctx->max_surface_count; ++*surfaceCount) {
res = nvenc_alloc_surface(avctx, *surfaceCount);
if (res)
@@ -1298,11 +1213,15 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
return 0;
error:
+av_fifo_freep(&ctx->timestamp_list);
+av_fifo_freep(&ctx->output_surface_ready_queue);
+av_fifo_f
[FFmpeg-devel] [PATCH 4/4] libavcodec/nvenc.c: CUDA frames support
---
libavcodec/nvenc.c | 308 +++--
1 file changed, 251 insertions(+), 57 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index d3856a4..cad554c 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -33,16 +33,31 @@
#include "libavutil/avassert.h"
#include "libavutil/opt.h"
#include "libavutil/mem.h"
+#include "libavutil/hwcontext.h"
#include "avcodec.h"
#include "internal.h"
#include "thread.h"
+
+#if CONFIG_CUDA
+#include
+#include "libavutil/hwcontext_cuda.h"
+#else
+
#if defined(_WIN32)
#define CUDAAPI __stdcall
#else
#define CUDAAPI
#endif
+typedef enum cudaError_enum {
+CUDA_SUCCESS = 0
+} CUresult;
+typedef int CUdevice;
+typedef void* CUcontext;
+typedef void* CUdeviceptr;
+#endif
+
#if defined(_WIN32)
#define LOAD_FUNC(l, s) GetProcAddress(l, s)
#define DL_CLOSE_FUNC(l) FreeLibrary(l)
@@ -51,12 +66,6 @@
#define DL_CLOSE_FUNC(l) dlclose(l)
#endif
-typedef enum cudaError_enum {
-CUDA_SUCCESS = 0
-} CUresult;
-typedef int CUdevice;
-typedef void* CUcontext;
-
typedef CUresult(CUDAAPI *PCUINIT)(unsigned int Flags);
typedef CUresult(CUDAAPI *PCUDEVICEGETCOUNT)(int *count);
typedef CUresult(CUDAAPI *PCUDEVICEGET)(CUdevice *device, int ordinal);
@@ -68,9 +77,13 @@ typedef CUresult(CUDAAPI *PCUCTXDESTROY)(CUcontext ctx);
typedef NVENCSTATUS (NVENCAPI* PNVENCODEAPICREATEINSTANCE)(NV_ENCODE_API_FUNCTION_LIST *functionList);
+#define MAX_REGISTERED_FRAMES 64
typedef struct NvencSurface
{
NV_ENC_INPUT_PTR input_surface;
+AVFrame *in_ref;
+NV_ENC_MAP_INPUT_RESOURCE in_map;
+int reg_idx;
int width;
int height;
@@ -105,11 +118,16 @@ typedef struct NvencDynLoadFunctions
int nvenc_device_count;
CUdevice nvenc_devices[16];
+#if !CONFIG_CUDA
#if defined(_WIN32)
HMODULE cuda_lib;
-HMODULE nvenc_lib;
#else
void* cuda_lib;
+#endif
+#endif
+#if defined(_WIN32)
+HMODULE nvenc_lib;
+#else
void* nvenc_lib;
#endif
} NvencDynLoadFunctions;
@@ -129,6 +147,7 @@ typedef struct NvencContext
NV_ENC_INITIALIZE_PARAMS init_encode_params;
NV_ENC_CONFIG encode_config;
CUcontext cu_context;
+CUcontext cu_context_internal;
int max_surface_count;
NvencSurface *surfaces;
@@ -138,6 +157,17 @@ typedef struct NvencContext
AVFifoBuffer *timestamp_list;
int64_t last_dts;
+struct {
+CUdeviceptr ptr;
+NV_ENC_REGISTERED_PTR regptr;
+int mapped;
+} registered_frames[MAX_REGISTERED_FRAMES];
+int nb_registered_frames;
+
+/* the actual data pixel format, different from
+ * AVCodecContext.pix_fmt when using hwaccel frames on input */
+enum AVPixelFormat data_pix_fmt;
+
void *nvencoder;
char *preset;
@@ -299,6 +329,18 @@ static av_cold int nvenc_dyload_cuda(AVCodecContext *avctx)
NvencContext *ctx = avctx->priv_data;
NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
+#if CONFIG_CUDA
+dl_fn->cu_init = cuInit;
+dl_fn->cu_device_get_count = cuDeviceGetCount;
+dl_fn->cu_device_get= cuDeviceGet;
+dl_fn->cu_device_get_name = cuDeviceGetName;
+dl_fn->cu_device_compute_capability = cuDeviceComputeCapability;
+dl_fn->cu_ctx_create= cuCtxCreate_v2;
+dl_fn->cu_ctx_pop_current = cuCtxPopCurrent_v2;
+dl_fn->cu_ctx_destroy = cuCtxDestroy_v2;
+
+return 1;
+#else
if (dl_fn->cuda_lib)
return 1;
@@ -332,6 +374,7 @@ error:
dl_fn->cuda_lib = NULL;
return 0;
+#endif
}
static av_cold int check_cuda_errors(AVCodecContext *avctx, CUresult err, const char *func)
@@ -357,7 +400,7 @@ static av_cold int nvenc_check_cuda(AVCodecContext *avctx)
switch (avctx->codec->id) {
case AV_CODEC_ID_H264:
-target_smver = avctx->pix_fmt == AV_PIX_FMT_YUV444P ? 0x52 : 0x30;
+target_smver = ctx->data_pix_fmt == AV_PIX_FMT_YUV444P ? 0x52 : 0x30;
break;
case AV_CODEC_ID_H265:
target_smver = 0x52;
@@ -481,8 +524,10 @@ static av_cold void nvenc_unload_nvenc(AVCodecContext *avctx)
dl_fn->nvenc_device_count = 0;
+#if !CONFIG_CUDA
DL_CLOSE_FUNC(dl_fn->cuda_lib);
dl_fn->cuda_lib = NULL;
+#endif
dl_fn->cu_init = NULL;
dl_fn->cu_device_get_count = NULL;
@@ -504,13 +549,33 @@ static av_cold int nvenc_setup_device(AVCodecContext *avctx)
CUresult cu_res;
CUcontext cu_context_curr;
+ctx->data_pix_fmt = avctx->pix_fmt;
+
+#if CONFIG_CUDA
+if (avctx->pix_fmt == AV_PIX_FMT_CUDA) {
+AVHWFramesContext *frames_ctx;
+AVCUDADeviceContext *device_hwctx;
+
+if (!avctx->hw_frames_ctx) {
+av_log(avctx, AV_LOG_ERROR, "hw_frames_ctx must be set when using GPU frames as input\n");
+return AVERROR(EINVAL);
+}
+
+frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
+device_hwctx = fr
Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS
On 5/20/16, Christophe Gisquet wrote: > Hi, > > 2016-05-20 1:55 GMT+02:00 Lukasz Marek : >> Is Derek revoked to commit or what? Couldn't he just commit this patch and >> leave? :P I was a problem for some people, but I see they still have >> problems. Let people with problems go away with they problems. > > Sorry if you felt ganged up on previously. Hopefully the new Code of > Conduct will avoid that such situations raise to an unsufferable > level. > > But whatever bad technical blood there have been between the two of > you, and whoever I may agree technically with, this is uncalled for. > You're just adding fuel to a tense situation, and causing distress to > someone. > > This type of comment is exactly what should not be allowed by the Code > of Conduct. That's adding insult to the injury. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/10] avcodec/dca_parser: improve frame end search
On Fri, May 20, 2016 at 04:46:31PM -0300, James Almer wrote: > On 5/20/2016 2:40 PM, foo86 wrote: > > On Fri, May 13, 2016 at 12:48:28PM +0300, foo86 wrote: > >> Parse core frame size directly when searching for frame end instead of > >> using value extracted from previous frame. > >> > >> Account for unused bits when calculating sync word distance for 14-bit > >> streams to avoid alias sync detection. > >> > >> Parse EXSS frame size and skip over EXSS frame to avoid alias sync > >> detection. > >> --- > >> libavcodec/dca_parser.c | 94 > >> + > >> 1 file changed, 80 insertions(+), 14 deletions(-) > > > > Fixes parser failure with the following sample: https://0x0.st/q4G.dts > > Seems to happen with codec copy only, two frames were being treated as one. > Decoding doesn't seem affected by this patch. framecrc output looks the same > before and after. For me it is the opposite: alias sync word in EXSS area at frame 21 results in a frame split in two without this patch (the second split "frame" fails to decode). This causes errors printed during decoding, and resulting framecrc output is different (see attached files). #software: Lavf57.36.100 #tb 0: 1/192000 #media_type 0: audio #codec_id 0: pcm_s24le #sample_rate 0: 192000 #channel_layout 0: 60f 0, 0, 0, 2048,36864, 0x60a47074 0, 2048, 2048, 2048,36864, 0xbd114c5c 0, 4096, 4096, 2048,36864, 0x0b7243ce 0, 6144, 6144, 2048,36864, 0x7f8c5b6c 0, 8192, 8192, 2048,36864, 0x02f96b0a 0, 10240, 10240, 2048,36864, 0xccf6f3fe 0, 12288, 12288, 2048,36864, 0x8c06a646 0, 14336, 14336, 2048,36864, 0x0dce889c 0, 16384, 16384, 2048,36864, 0xa650826b 0, 18432, 18432, 2048,36864, 0x9bb45a74 0, 20480, 20480, 2048,36864, 0xf011921f 0, 22528, 22528, 2048,36864, 0xb6b4db5b 0, 24576, 24576, 2048,36864, 0x51e3283f 0, 26624, 26624, 2048,36864, 0xe58e7024 0, 28672, 28672, 2048,36864, 0x2088d810 0, 30720, 30720, 2048,36864, 0xba88dd19 0, 32768, 32768, 2048,36864, 0xe72278cb 0, 34816, 34816, 2048,36864, 0x5096ec0e 0, 36864, 36864, 2048,36864, 0x1faddc6f 0, 38912, 38912, 2048,36864, 0xa7cb41d5 0, 40960, 40960, 1984,35712, 0x7fbd6605 0, 47104, 47104, 2048,36864, 0x18cb02c9 0, 49152, 49152, 2048,36864, 0x8290b628 0, 51200, 51200, 2048,36864, 0x00065519 0, 53248, 53248, 2048,36864, 0x26302fd0 0, 55296, 55296, 2048,36864, 0x0fc5652c 0, 57344, 57344, 2048,36864, 0x80f992f5 0, 59392, 59392, 2048,36864, 0x770d7bd3 0, 61440, 61440, 2048,36864, 0xf06ff731 0, 63488, 63488, 2048,36864, 0xf42f36a2 0, 65536, 65536, 2048,36864, 0x40496db9 0, 67584, 67584, 2048,36864, 0x88e3c586 0, 69632, 69632, 2048,36864, 0x4027756f 0, 71680, 71680, 2048,36864, 0x30e1e2af 0, 73728, 73728, 2048,36864, 0x794f500e 0, 75776, 75776, 2048,36864, 0x1388d154 0, 77824, 77824, 2048,36864, 0x55fef3fa 0, 79872, 79872, 2048,36864, 0x631de608 0, 81920, 81920, 2048,36864, 0xa479ecfe 0, 83968, 83968, 2048,36864, 0xe561fe79 0, 86016, 86016, 2048,36864, 0x806ae121 0, 88064, 88064, 2048,36864, 0xfa832f7d 0, 90112, 90112, 2048,36864, 0x4ba72c89 0, 92160, 92160, 2048,36864, 0xb107a5d9 0, 94208, 94208, 2048,36864, 0x0871c610 0, 96256, 96256, 2048,36864, 0xc74e0148 0, 98304, 98304, 2048,36864, 0x1134ce2e 0, 100352, 100352, 2048,36864, 0x4bf46961 0, 102400, 102400, 2048,36864, 0xee4c58ea 0, 104448, 104448, 2048,36864, 0x84cb078e #software: Lavf57.36.100 #tb 0: 1/192000 #media_type 0: audio #codec_id 0: pcm_s24le #sample_rate 0: 192000 #channel_layout 0: 60f 0, 0, 0, 2048,36864, 0x60a47074 0, 2048, 2048, 2048,36864, 0xbd114c5c 0, 4096, 4096, 2048,36864, 0x0b7243ce 0, 6144, 6144, 2048,36864, 0x7f8c5b6c 0, 8192, 8192, 2048,36864, 0x02f96b0a 0, 10240, 10240, 2048,36864, 0xccf6f3fe 0, 12288, 12288, 2048,36864, 0x8c06a646 0, 14336, 14336, 2048,36864, 0x0dce889c 0, 16384, 16384, 2048,36864, 0xa650826b 0, 18432, 18432, 2048,36864, 0x9bb45a74 0, 20480, 20480, 2048,36864, 0xf011921f 0, 22
Re: [FFmpeg-devel] [PATCH] avcodec/sgirledec: simplify, no need to use reget buffer
On Fri, May 20, 2016 at 09:32:43PM +0200, Paul B Mahol wrote: > Hi, > > patch attached. > sgirledec.c | 32 +++- > 1 file changed, 7 insertions(+), 25 deletions(-) > 72db54533a4087fed1e0ac1ebd537fe566f2ca87 > 0001-avcodec-sgirledec-simplify-no-need-to-use-reget-buff.patch > From da5353cd2d54de387bb1617c4fc58f919053bc43 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Fri, 20 May 2016 21:30:29 +0200 > Subject: [PATCH] avcodec/sgirledec: simplify, no need to use reget buffer LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/10] avcodec/dca_parser: improve frame end search
On 5/20/2016 8:28 PM, foo86 wrote: > On Fri, May 20, 2016 at 04:46:31PM -0300, James Almer wrote: >> On 5/20/2016 2:40 PM, foo86 wrote: >>> On Fri, May 13, 2016 at 12:48:28PM +0300, foo86 wrote: Parse core frame size directly when searching for frame end instead of using value extracted from previous frame. Account for unused bits when calculating sync word distance for 14-bit streams to avoid alias sync detection. Parse EXSS frame size and skip over EXSS frame to avoid alias sync detection. --- libavcodec/dca_parser.c | 94 + 1 file changed, 80 insertions(+), 14 deletions(-) >>> >>> Fixes parser failure with the following sample: https://0x0.st/q4G.dts >> >> Seems to happen with codec copy only, two frames were being treated as one. >> Decoding doesn't seem affected by this patch. framecrc output looks the same >> before and after. > > For me it is the opposite: alias sync word in EXSS area at frame 21 > results in a frame split in two without this patch (the second split > "frame" fails to decode). > > This causes errors printed during decoding, and resulting framecrc > output is different (see attached files). "ffmpeg -i q4G.dts -c:a copy -f framecrc -" gave me the following before the patch #software: Lavf57.36.100 #tb 0: 1/9 #media_type 0: audio #codec_id 0: dts #sample_rate 0: 192000 #channel_layout 0: 60f 0, 0, 0, 960,15520, 0x4e922c28 0,960,960, 960,15620, 0x0aa208ee 0, 1920, 1920, 960,15604, 0x5ff63a0b 0, 2880, 2880, 960,15516, 0xeeabf0c9 0, 3840, 3840, 960,15476, 0x53f46290 0, 4800, 4800, 960,15348, 0x477e8987 0, 5760, 5760, 960,15252, 0x2b20725b 0, 6720, 6720, 960,15304, 0x9d60b356 0, 7680, 7680, 960,15172, 0x19e359e4 0, 8640, 8640, 960,15092, 0x1dc6f776 0, 9600, 9600, 960,15064, 0xc2385e65 0, 10560, 10560, 960,15048, 0x50d75a33 0, 11520, 11520, 960,15132, 0x3eb47e67 0, 12480, 12480, 960,15188, 0x6f16aad6 0, 13440, 13440, 960,15360, 0xc481d7c6 0, 14400, 14400, 960,15508, 0x2da8a9f4 0, 15360, 15360, 960,15380, 0x036fe8c8 0, 16320, 16320, 960,15372, 0xa815aa65 0, 17280, 17280, 960,15352, 0xc9f7b3db 0, 18240, 18240, 960,15288, 0x62a15e11 0, 19200, 19200, 960,12746, 0x44ee1fa5 0, 20160, 20160, 1920, 2530, 0xf4a2af4c 0, 22080, 22080, 960,15244, 0xa8948fa5 0, 23040, 23040, 960,15264, 0x47539652 0, 24000, 24000, 960,15300, 0x10adf509 0, 24960, 24960, 960,15356, 0x3403a586 0, 25920, 25920, 960,15436, 0xcbea18b7 0, 26880, 26880, 960,15424, 0x2ce91378 0, 27840, 27840, 960,15524, 0xf3ba523c 0, 28800, 28800, 960,15544, 0xa1504354 0, 29760, 29760, 960,15528, 0x6bc826fd 0, 30720, 30720, 960,15492, 0x4f89f07a 0, 31680, 31680, 960,15456, 0x002c4ac0 0, 32640, 32640, 960,15388, 0x78c854be 0, 33600, 33600, 960,15372, 0xce9954e5 0, 34560, 34560, 960,15268, 0x1c5bceda 0, 35520, 35520, 960,15288, 0x60acfb3d 0, 36480, 36480, 960,15240, 0xb42d7f7b 0, 37440, 37440, 960,15316, 0xd6080d5a 0, 38400, 38400, 960,15368, 0xc2b65528 0, 39360, 39360, 960,15476, 0xa01f2806 0, 40320, 40320, 960,15448, 0x2e0121ef 0, 41280, 41280, 960,15384, 0x891dd887 0, 42240, 42240, 960,15384, 0x31cea7b0 0, 43200, 43200, 960,15316, 0xaa040ae8 0, 44160, 44160, 960,15356, 0xa13cfd43 0, 45120, 45120, 960,15388, 0xf6a81182 0, 46080, 46080, 960,15324, 0x72e4de3f 0, 47040, 47040, 960,15252, 0x5d84b107 0, 48000, 48000, 960,15216, 0xe9656c9b 0, 48960, 48960, 960,15232, 0x6930b4a3 But you're right that it was also failing during decoding. Not sure how i missed or why i thought the framecrc output was the same. So nevermind my previous comment. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/10] avcodec/dca_parser: improve frame end search
On Fri, May 20, 2016 at 08:51:53PM -0300, James Almer wrote: > "ffmpeg -i q4G.dts -c:a copy -f framecrc -" gave me the following > before the patch > > #software: Lavf57.36.100 > #tb 0: 1/9 > #media_type 0: audio > #codec_id 0: dts > #sample_rate 0: 192000 > #channel_layout 0: 60f > 0, 0, 0, 960,15520, 0x4e922c28 > 0,960,960, 960,15620, 0x0aa208ee > 0, 1920, 1920, 960,15604, 0x5ff63a0b > 0, 2880, 2880, 960,15516, 0xeeabf0c9 > 0, 3840, 3840, 960,15476, 0x53f46290 > 0, 4800, 4800, 960,15348, 0x477e8987 > 0, 5760, 5760, 960,15252, 0x2b20725b > 0, 6720, 6720, 960,15304, 0x9d60b356 > 0, 7680, 7680, 960,15172, 0x19e359e4 > 0, 8640, 8640, 960,15092, 0x1dc6f776 > 0, 9600, 9600, 960,15064, 0xc2385e65 > 0, 10560, 10560, 960,15048, 0x50d75a33 > 0, 11520, 11520, 960,15132, 0x3eb47e67 > 0, 12480, 12480, 960,15188, 0x6f16aad6 > 0, 13440, 13440, 960,15360, 0xc481d7c6 > 0, 14400, 14400, 960,15508, 0x2da8a9f4 > 0, 15360, 15360, 960,15380, 0x036fe8c8 > 0, 16320, 16320, 960,15372, 0xa815aa65 > 0, 17280, 17280, 960,15352, 0xc9f7b3db > 0, 18240, 18240, 960,15288, 0x62a15e11 > 0, 19200, 19200, 960,12746, 0x44ee1fa5 > 0, 20160, 20160, 1920, 2530, 0xf4a2af4c Yeah, this may look like combined frame due to doubled duration, but in fact this 2530 byte frame is a fragment that belongs to the previous frame (you can tell that the previous frame is shorter by approximately the same number of bytes). Doubled duration actually comes from misinterpreted core frame header (parser interprets arbitrary EXSS data as core frame header). > 0, 22080, 22080, 960,15244, 0xa8948fa5 > 0, 23040, 23040, 960,15264, 0x47539652 > 0, 24000, 24000, 960,15300, 0x10adf509 > 0, 24960, 24960, 960,15356, 0x3403a586 > 0, 25920, 25920, 960,15436, 0xcbea18b7 > 0, 26880, 26880, 960,15424, 0x2ce91378 > 0, 27840, 27840, 960,15524, 0xf3ba523c > 0, 28800, 28800, 960,15544, 0xa1504354 > 0, 29760, 29760, 960,15528, 0x6bc826fd > 0, 30720, 30720, 960,15492, 0x4f89f07a > 0, 31680, 31680, 960,15456, 0x002c4ac0 > 0, 32640, 32640, 960,15388, 0x78c854be > 0, 33600, 33600, 960,15372, 0xce9954e5 > 0, 34560, 34560, 960,15268, 0x1c5bceda > 0, 35520, 35520, 960,15288, 0x60acfb3d > 0, 36480, 36480, 960,15240, 0xb42d7f7b > 0, 37440, 37440, 960,15316, 0xd6080d5a > 0, 38400, 38400, 960,15368, 0xc2b65528 > 0, 39360, 39360, 960,15476, 0xa01f2806 > 0, 40320, 40320, 960,15448, 0x2e0121ef > 0, 41280, 41280, 960,15384, 0x891dd887 > 0, 42240, 42240, 960,15384, 0x31cea7b0 > 0, 43200, 43200, 960,15316, 0xaa040ae8 > 0, 44160, 44160, 960,15356, 0xa13cfd43 > 0, 45120, 45120, 960,15388, 0xf6a81182 > 0, 46080, 46080, 960,15324, 0x72e4de3f > 0, 47040, 47040, 960,15252, 0x5d84b107 > 0, 48000, 48000, 960,15216, 0xe9656c9b > 0, 48960, 48960, 960,15232, 0x6930b4a3 > > But you're right that it was also failing during decoding. Not sure how > i missed or why i thought the framecrc output was the same. So nevermind > my previous comment. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avlanguage: deprecate av_convert_lang_to and make it internal
On 5/13/2016 6:10 PM, James Almer wrote: > The header was never installed and the function is only used in libavformat > > Signed-off-by: James Almer > --- > libavformat/asfdec_f.c| 2 +- > libavformat/asfdec_o.c| 2 +- > libavformat/asfenc.c | 2 +- > libavformat/avienc.c | 2 +- > libavformat/avlanguage.c | 11 +-- > libavformat/avlanguage.h | 7 +++ > libavformat/matroskaenc.c | 2 +- > 7 files changed, 21 insertions(+), 7 deletions(-) Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/10] avcodec/dca: simplify 'residual ok' flag tracking
On 5/13/2016 6:48 AM, foo86 wrote: > Move this from separate structure field to a packet flag. > > Behavior should be equivalent, except that residual flag is now properly > cleared when packet has no core frame at all. > > Also print a message when forcing recovery mode due to invalid residual > to make debugging easier. Applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 05/10] avcodec/dca: use LUT for LBR frequency ranges
On 5/13/2016 6:48 AM, foo86 wrote: > Values for unsupported frequencies > 48000 Hz are still included (parser > will make use of them). > > Also convert sampling frequencies array to unsigned. Applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_ahistogram: raise minimum acmax to 1
On Fri, May 20, 2016 at 08:04:28PM +0200, Paul B Mahol wrote: > On 5/20/16, Michael Niedermayer wrote: > > If acmax can be 0 then it could result in a division by 0 > > Fixes CID1351345 > > But there is cast to double. yes but the result (aa) is assigned to int (h) which is undefined behavior (if it can happen) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to openh264 1.6
On Fri, May 20, 2016 at 04:27:17PM +0100, Ricardo Constantino wrote: > On 20 May 2016 at 11:37, Michael Niedermayer wrote: > > as one testing ffmpeg with openh264 (building at least) > > > > i have mixed feelings about this, it would cause me to drop further > > testing with openh264 in all releases OR in git master > > because releases wont build with git master of openh264 and > > master wont build with older openh264 > > having 2 different versions installed would be possible but i will not > > go to that troubble and i suspect noone else will either > > I see very few distros actually packaging OpenH264 (it's mainly only > used by Firefox, but there's a GStreamer plugin for it too, I think), > but when they do it's either 1.5 (Archlinux AUR) or 1.5.3 (Fedora > 23-25). Not using Cisco's binaries voids the patent protection, so I > guess that's why they don't package it. > Depends on whether FFmpeg cares about supporting non-releases. If it > doesn't it should probably be noted somewhere, at least in the wiki. i think you slightly misunderstand if the patch is applied ffmpeg releases will not be tested anymore (by me) or ffmpeg git master will not be tested anymore (by me) with openh264 as theres no common openh264 that works with both. 1.6 does not work with ffmpeg releases IIUC and this patch would drop support for openh264 before 1.6 in git master [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Tee improvement - discussion
On Fri, May 20, 2016 at 12:06:34AM +0200, Marton Balint wrote: > > On Thu, 19 May 2016, Nicolas George wrote: > > >Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit : > >>My current idea is to create queue for each output (as Marton suggested) and > >>process each output in separate thread. I was also considering using just > >>single queue, but since the AVPackets are referenced counted, the memory > >>overhead is negligible and using multiple queues will simplify the code. > >>Apart from getting advantage of non-blocking processing with multiple slave > >>muxers, error handling will also be improved. > > > >>Another question is what to do when some of the queues becomes full, > >>discussed options were so far: > >>- Block write_packet call until the queue frees - this might be useful > >>when producer is faster than consumer, and we don't want to drop any packets > >>when recording to file. > >>- Drop some yet unprocessed packets (until next keyframe, or free some > >>portion of queue) to free the queue - this might be useful for network > >>outputs. > > > >I must say, I am not very happy with the direction this project takes. > > > >Non-blocking muxers (and demuxers, and protocols) is a white whale for our > >API: we really really want it, but it huge and very hard to catch. > > > >It is something that needs to be implemented globally with a very careful > >design. Definitely not something that can be added in a corner of an obscure > >muxer. We already went down that path twice, with the thread for the UDP > >protocol and with running demuxer in threads in FFmpeg. Both did lead to > >endless complications: bugs, inconsistencies, portability trouble. > > What caused these complications? Do you have some references? i dont know, what i remember as udp problems are things that shouldnt affect tee like: some UDP "users" like RT*P bypass the public API and pull the UDP fd out of the demuxer and then try to use it polling and stuff (ffurl_get_file_handle) this doesnt work so well, as teh fd is on the input side of the que and what came out of the udp code is on the output side and in different threads another issue with udp i remember is timing packets should have "transmit times" from the muxer in them so they get sent at the correct time, thats not done even though muxers like mpeg-ps calculate these times correctly [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
