Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)
Hello Michael, On Tue, Feb 07, 2017 at 03:09:56AM +0100, Michael Niedermayer wrote: > > What about the other patches from that series? > > > The second one is purely cosmetic (looks useful to me but not much > > of concern) > > I have no oppinion about // vs /**/ comments but in the absence of > a reason to change them my gut feeling leans toward leaving things > as they are for "git blame" simplification. No objection. > > while the third (tiny) one is about correcting an inverted > > explanation in a comment. > > I think the 3rd depends on the 2nd No, the third is standalone. It was possibly wrong to put them in the same series, but otherwise a confusion would be probably easy, too. > another point which was brought up by jb on IRC and in RL longer ago > was that ideally the author field in git should contain a name. > It may help with contacting one in the far future or with simply > refering to the author as in > who wrote the cinepack optimizations? > Author: addr-see-the-webs...@aetey.se Contact data is not identity even though this fact is ignored in some widely spread (misled) practices, which the above example illustrates well. There are actually two separate questions: Q: Who wrote the cinepak optimizations? A: A person known as Rl @ Aetey Global Technologies AB. Q: How to contact him/her? A: The author does not wish to publicize any contact handle which is open to abuse, like a permanent mail address. YMMV. > is a bit cumbersome but its not mine to judge that. If you want > that in the author field, thats ok as far as iam concerned, i just > have difficulty imagening that being intended over a pronouncable > name (even if thats a pseudonym) before The data in the address field is not the/a pseudonym but a hint to a possibly existing way to contact the author (no guarantee). If you or any of the developers here wish to have a long term contact handle to me, I will gladly provide it. But it will be invalidated as soon as it becomes published or leaked. Does this look reasonable to you? Regards, Rune ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote: > On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote: > [...] > > > No, code quality is not outside the scope of your patch. > > > > Code quality is a subjective matter. > > > > I'm not going to fight with you Appreciated. > several developers consider your patch > does not pass the quality requirements of the project. It's arbitrary, > [... skipped ...], but that's the current policy of the project. Well said. > Changing that policy is outside the scope of this patch. :) > [...] > > > The use of the environment variable is not tolerable, this is a blocker. > > > > It is explicitly specified that it is _not_ being used, > > Then please drop the dead code. Ok, why not. Still, given the disapproval of the "code quality" without a tangible criteria to follow, I can hardly take any accomodating steps, barring the omission of the unused code - would this step be enough? Regards, Rune ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] imgutils: Document av_image_get_buffer_size()
--- libavutil/imgutils.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h index 67063a2..ac1bcb8 100644 --- a/libavutil/imgutils.h +++ b/libavutil/imgutils.h @@ -169,7 +169,12 @@ int av_image_fill_arrays(uint8_t *dst_data[4], int dst_linesize[4], * Return the size in bytes of the amount of data required to store an * image with the given parameters. * - * @param[in] align the assumed linesize alignment + * @param pix_fmt the pixel format of the image + * @param widththe width of the image in pixels + * @param height the height of the image in pixels + * @param alignthe assumed linesize alignment + * @return the size in bytes required for src, a negative error code + * in case of failure */ int av_image_get_buffer_size(enum AVPixelFormat pix_fmt, int width, int height, int align); -- 2.10.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Tue, Feb 7, 2017 at 3:57 PM, wrote: > On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote: >> On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote: >> [...] >> > > No, code quality is not outside the scope of your patch. >> > >> > Code quality is a subjective matter. >> > >> >> I'm not going to fight with you > > Appreciated. > >> several developers consider your patch >> does not pass the quality requirements of the project. It's arbitrary, >> [... skipped ...], but that's the current policy of the project. > > Well said. > >> Changing that policy is outside the scope of this patch. > > :) > >> [...] >> > > The use of the environment variable is not tolerable, this is a blocker. >> > >> > It is explicitly specified that it is _not_ being used, >> >> Then please drop the dead code. > > Ok, why not. > > Still, given the disapproval of the "code quality" without a tangible > criteria to follow, I can hardly take any accomodating steps, barring > the omission of the unused code - would this step be enough? > The code duplication is still enormous and makes the entire approach look rather questionable, and on top of that some built-in yuv conversion is not really appropriate. Packing into different RGB formats is one thing, but actually converting to another color format entirely is quite something else. Whats next, handling all sorts of various yuv colorspaces and subsampling factors? So at the very least the YUV part should be dropped at this point, its not a decoders job to convert from RGB to YUV. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
Hi, On Tue, Feb 7, 2017 at 9:57 AM, wrote: > Still, given the disapproval of the "code quality" without a tangible > criteria to follow, I can hardly take any accomodating steps, barring > the omission of the unused code - would this step be enough? So, right now, the decoder outputs pal8 vs. rgb24 depending on the internal format of the bitstream, and you're changing it to do conversion so it outputs a selectable output format directly, right? (And then there's some discussion over how to select the format.) My personal opinion is that it's not worth it to do colorspace conversion of any sort, including palette resolution, in a decoder. I understand using swscale to do the conversion is slower, but cinepak is a fringe codec and a new haswell i7 isn't that expensive. (Code maintenance has a cost also.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Tue, 7 Feb 2017 15:57:03 +0100 u-9...@aetey.se wrote: > On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote: > > On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote: > > [...] > > > > No, code quality is not outside the scope of your patch. > > > > > > Code quality is a subjective matter. > > > > > > > I'm not going to fight with you > > Appreciated. > > > several developers consider your patch > > does not pass the quality requirements of the project. It's arbitrary, > > [... skipped ...], but that's the current policy of the project. > > Well said. > > > Changing that policy is outside the scope of this patch. > > :) > > > [...] > > > > The use of the environment variable is not tolerable, this is a > > > > blocker. > > > > > > It is explicitly specified that it is _not_ being used, > > > > Then please drop the dead code. > > Ok, why not. > > Still, given the disapproval of the "code quality" without a tangible > criteria to follow, I can hardly take any accomodating steps, barring > the omission of the unused code - would this step be enough? Bad: - dead code - code duplication - not using standard API mechanisms (get_format) - using unusual mechanisms that are normally not used in FFmpeg libraries or libraries in general (configuration via getenv) It's not so complicated if you make an effort to try to understand. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: Mark some codecs with threadsafe init as such
Signed-off-by: Derek Buitenhuis
---
I wrote this in Nov 2015, and it has resided on my GitHub fork in a branch
since then, since I never ot around to finishing it. I noticed a spike in
interest in the 'feature', so I rebase and am forwarding this, in case it
is of interest.
During the triage I noted the following codecs need to be properly fixed:
* cavs
* asv
* bink
* ... more ...
CC me in any reply you feel needs my direct response.
---
libavcodec/aasc.c | 1 +
libavcodec/aic.c | 1 +
libavcodec/anm.c | 1 +
libavcodec/ansi.c | 1 +
libavcodec/aura.c | 1 +
libavcodec/avrndec.c | 1 +
libavcodec/avs.c | 1 +
libavcodec/avuidec.c | 1 +
libavcodec/bethsoftvideo.c | 1 +
libavcodec/bfi.c | 1 +
libavcodec/bmvvideo.c | 1 +
libavcodec/c93.c | 1 +
libavcodec/cllc.c | 1 +
libavcodec/cyuv.c | 2 ++
libavcodec/fraps.c | 1 +
libavcodec/lcldec.c| 2 ++
libavcodec/pngdec.c| 3 ++-
libavcodec/r210dec.c | 3 +++
libavcodec/utvideodec.c| 1 +
libavcodec/v408dec.c | 2 ++
libavcodec/vble.c | 1 +
libavcodec/zerocodec.c | 1 +
22 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aasc.c b/libavcodec/aasc.c
index fd63aba..58cc3c8 100644
--- a/libavcodec/aasc.c
+++ b/libavcodec/aasc.c
@@ -159,4 +159,5 @@ AVCodec ff_aasc_decoder = {
.close = aasc_decode_end,
.decode = aasc_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/aic.c b/libavcodec/aic.c
index ff8e392..4faa574 100644
--- a/libavcodec/aic.c
+++ b/libavcodec/aic.c
@@ -492,4 +492,5 @@ AVCodec ff_aic_decoder = {
.decode = aic_decode_frame,
.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.init_thread_copy = ONLY_IF_THREADS_ENABLED(aic_decode_init),
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index 29d59fb..7268418 100644
--- a/libavcodec/anm.c
+++ b/libavcodec/anm.c
@@ -199,4 +199,5 @@ AVCodec ff_anm_decoder = {
.close = decode_end,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/ansi.c b/libavcodec/ansi.c
index 19c88d8..3c82dcd 100644
--- a/libavcodec/ansi.c
+++ b/libavcodec/ansi.c
@@ -482,4 +482,5 @@ AVCodec ff_ansi_decoder = {
.close = decode_close,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/aura.c b/libavcodec/aura.c
index 5f84d95..5ef9316 100644
--- a/libavcodec/aura.c
+++ b/libavcodec/aura.c
@@ -105,4 +105,5 @@ AVCodec ff_aura2_decoder = {
.init = aura_decode_init,
.decode = aura_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/avrndec.c b/libavcodec/avrndec.c
index cdec99c..c37f996 100644
--- a/libavcodec/avrndec.c
+++ b/libavcodec/avrndec.c
@@ -170,4 +170,5 @@ AVCodec ff_avrn_decoder = {
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
.max_lowres = 3,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/avs.c b/libavcodec/avs.c
index 345d628..66724d4 100644
--- a/libavcodec/avs.c
+++ b/libavcodec/avs.c
@@ -186,4 +186,5 @@ AVCodec ff_avs_decoder = {
.decode = avs_decode_frame,
.close = avs_decode_end,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/avuidec.c b/libavcodec/avuidec.c
index 5117844..4cf620d 100644
--- a/libavcodec/avuidec.c
+++ b/libavcodec/avuidec.c
@@ -127,4 +127,5 @@ AVCodec ff_avui_decoder = {
.init = avui_decode_init,
.decode = avui_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/bethsoftvideo.c b/libavcodec/bethsoftvideo.c
index 97b745d..274516b 100644
--- a/libavcodec/bethsoftvideo.c
+++ b/libavcodec/bethsoftvideo.c
@@ -163,4 +163,5 @@ AVCodec ff_bethsoftvid_decoder = {
.close = bethsoftvid_decode_end,
.decode = bethsoftvid_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/bfi.c b/libavcodec/bfi.c
index 6727629..233a1d2 100644
--- a/libavcodec/bfi.c
+++ b/libavcodec/bfi.c
@@ -185,4 +185,5 @@ AVCodec ff_bfi_decoder = {
.close = bfi_decode_close,
.decode = bfi_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/bmvvideo.c b/libavcodec/bmvvideo.c
index 97f850d..dbbc100 100644
--
Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder
On Fri, Feb 03, 2017 at 11:42:03AM +0100, u-9...@aetey.se wrote: > On Fri, Feb 03, 2017 at 11:14:28AM +0100, wm4 wrote: > > > On a 16-bit-per-pixel output with a CPU-based decoder you will > > > not find _any_ over 25% of Cinepak speed. Raw video can not compete > > > either when indata delivery bandwidth si limited. > > I can't take this seriously, but I won't go and try finding a better > > codec just to make a point. Of course any benchmark result makes sense only within a carefully specified context. It was incautious of me to make a statement in such a general way. I have to admit that the number 25% was not measured but extrapolated from a specific test I made three years ago. It is impossible to repeat that test (the hardware is gone) and the video data was a specific sample which may have incurred a bias. That's why now I have done a new test, with 15 minutes taken from a (single) random movie as the input, compressed with ffmpeg to mpeg1video at quality 8 and to cinepak with default quality settings, which in this case yielded comparable quality. When I take the user part of the output of "time mplayer -fps 1 -vo null -quiet -vf format=fmt=bgr16 -sws 0" [*] I get the following numbers on two different computers with Intel CPUs running 32-bit code: (averaging/rounding after three runs) mpeg1, yuv420p23.6 (via the fast bilinear swscaler) cinepak, rgb2419.7 (via the fast bilinear swscaler) cinepak, internal rgb565 6.0 mpeg1, yuv420p52.1 (via the fast bilinear swscaler) cinepak, rgb2443.1 (via the fast bilinear swscaler) cinepak, internal rgb565 10.3 This corresponds to mpeg1 being for rgb565 output about 4-5 times slower than cinepak. I doubt that there is any other applicable codec with a faster decoder. Tell me if you find it, this will be appreciated. The "high color" 15-bit VQA was near cinepak in speed but it is unfortunately not practically usable. Regards, Rune [*] Remarkably, mplayer, an application with tight ties to ffmpeg, does not seem to choose the appropriate decoder output format itself, despite the availability of get_format() functionality... Would you tell me which video player does? or where the bug is? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Tue, Feb 07, 2017 at 04:23:50PM +0100, wm4 wrote: > > Still, given the disapproval of the "code quality" without a tangible > > criteria to follow, I can hardly take any accomodating steps, barring > > the omission of the unused code - would this step be enough? > > Bad: > - dead code Already slated to be removed, I wrote. > - code duplication Would you give me an estimation of how many lines of code are actually duplicated. I believe you just see the superficial resemblance, not the differences. > - not using standard API mechanisms (get_format) You have to take this back and look at the patch. > - using unusual mechanisms that are normally not used in FFmpeg This is the whole point of the improvement. If doing unusual useful things is a bad style here, I am leaving :) I do not believe you really insist on this point. > libraries or libraries in general (configuration via getenv) Ehh, wasn't this the "dead code" you complained about above? Let's strike away this point. So the only remaining unsettled point is which lines of code are duplicated / how they are to be refactored. I wrote about this change not being exactly trivial. May be I am not fit for this particular task? Give me a hand, show how to do refactoring without impacting readability and speed? Otherwise it would be a pity to throw away an improvement just because the author has his/her limitations. > It's not so complicated if you make an effort to try to understand. Indeed. Friendly yours, Rune ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Tue, Feb 07, 2017 at 04:17:30PM +0100, Hendrik Leppkes wrote: > On Tue, Feb 7, 2017 at 3:57 PM, wrote: > > Still, given the disapproval of the "code quality" without a tangible > > criteria to follow, I can hardly take any accomodating steps, barring > > the omission of the unused code - would this step be enough? > > The code duplication is still enormous and makes the entire approach Do you mean the about dozen lines which by the bitstream design are doing exactly the same but are repeated almost literally in every of the 10 finctions? This is the duplication I see, do you mean this or something else? > look rather questionable, and on top of that some built-in yuv > conversion is not really appropriate. Packing into different RGB Why not appropriate if it is useful? Any other way to do equally fast decoding to YUV? > formats is one thing, but actually converting to another color format > entirely is quite something else. Whats next, handling all sorts of You talk past me! What makes you accept the one but not the other? :) > various yuv colorspaces and subsampling factors? Why not, if there will be a data consumer with this hypothetical format and we will need speed? Why not? This _is_ efficient at the decoder, it is just many of the developers ignored this fact until now. > So at the very least the YUV part should be dropped at this point, its > not a decoders job to convert from RGB to YUV. What is the criteria to choose where the job is to be done? My point is efficiency. What is yours? Regards, Rune ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder
Hi, On Tue, Feb 7, 2017 at 12:04 PM, wrote: > cinepak, rgb2419.7 (via the fast bilinear swscaler) > cinepak, internal rgb565 6.0 The reason that your decoder-integrated colorspace convertor is so much faster than swscale is because swscale is converting internally to yuv420p using a scaling filter, and then back to rgb565 using another scaling filter. This is "easily" solved by adding a direct (possibly x86-simd-accelerated) rgb24-to-rgb565 converter into libswscale/swscale_unscaled.c, which would likely have nearly identical performance to what you're seeing here. Possibly even faster, because you're allowing for simd optimizations. HTH, Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder
On Tue, 7 Feb 2017 12:54:23 -0500 "Ronald S. Bultje" wrote: > Hi, > > On Tue, Feb 7, 2017 at 12:04 PM, wrote: > > > cinepak, rgb2419.7 (via the fast bilinear swscaler) > > cinepak, internal rgb565 6.0 > > > The reason that your decoder-integrated colorspace convertor is so much > faster than swscale is because swscale is converting internally to yuv420p > using a scaling filter, and then back to rgb565 using another scaling > filter. This is "easily" solved by adding a direct (possibly > x86-simd-accelerated) rgb24-to-rgb565 converter into > libswscale/swscale_unscaled.c, which would likely have nearly identical > performance to what you're seeing here. Possibly even faster, because > you're allowing for simd optimizations. I'm also wondering how much performance the 3 byte rgb24 format costs as opposed to using a 4 byte padded format like rgb0. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Tue, Feb 7, 2017 at 6:48 PM, wrote: > On Tue, Feb 07, 2017 at 04:17:30PM +0100, Hendrik Leppkes wrote: >> On Tue, Feb 7, 2017 at 3:57 PM, wrote: >> > Still, given the disapproval of the "code quality" without a tangible >> > criteria to follow, I can hardly take any accomodating steps, barring >> > the omission of the unused code - would this step be enough? >> >> The code duplication is still enormous and makes the entire approach > > Do you mean the about dozen lines which by the bitstream design are > doing exactly the same but are repeated almost literally in every of > the 10 finctions? This is the duplication I see, do you mean this or > something else? > >> look rather questionable, and on top of that some built-in yuv >> conversion is not really appropriate. Packing into different RGB > > Why not appropriate if it is useful? > Any other way to do equally fast decoding to YUV? > >> formats is one thing, but actually converting to another color format >> entirely is quite something else. Whats next, handling all sorts of > > You talk past me! What makes you accept the one but not the other? :) > >> various yuv colorspaces and subsampling factors? > > Why not, if there will be a data consumer with this hypothetical format > and we will need speed? Why not? This _is_ efficient at the decoder, > it is just many of the developers ignored this fact until now. If you don't understand why this is bad, then trying to explain it again is just wasted time. I'll give you a hint: What if every codec would do this? Surely that would be faster, but noone in their right mind would ever want to work on such an abonimation. > >> So at the very least the YUV part should be dropped at this point, its >> not a decoders job to convert from RGB to YUV. > > What is the criteria to choose where the job is to be done? > My point is efficiency. What is yours? > If you want effieciency above everything else, maybe you should write a very specific application tailored for your one specific use-case, and not use a generic multimedia frame work like ffmpeg. Anyway, you don't seem to be understanding our points at all, so the chances of this ever being commited are reaching zero. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
Hello Ronald, On Tue, Feb 07, 2017 at 10:29:01AM -0500, Ronald S. Bultje wrote: > So, right now, the decoder outputs pal8 vs. rgb24 depending on the internal > format of the bitstream, and you're changing it to do conversion so it > outputs a selectable output format directly, right? (And then there's some > discussion over how to select the format.) A very good summary. The only detail to note is that format conversion has always been done inside the Cinepak decoder, the change does not "introduce" it in any way. What is done is basically splitting the format conversion function which until now did all the three conversions (palettized->pal8; grayscale->rgb24; "cinepak"->rgb24) into separate functions, as a result each function becoming simpler, faster and making it easy to produce "any" desired format. > My personal opinion is that it's not worth it to do colorspace conversion > of any sort, including palette resolution, in a decoder. I understand using > swscale to do the conversion is slower, but cinepak is a fringe codec and a > new haswell i7 isn't that expensive. (Code maintenance has a cost also.) Your point about code maintenance cost basically boils down to Cinepak not being considered worth improvement, because any change incurs a cost here (among others, the time we spend on this discussion) and because it is easy somewhere else in a foreign usage case to replace hardware to more capable. The first part makes sense but the other is hardly solid. One of the users spent quite a bit of effort on implementing the speedup, this is at least some kind of indication of the usefulness. Regards, Rune ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264dec: use OFFSET macro
On Mon, Feb 06, 2017 at 05:14:57PM +0100, Matthieu Bouron wrote: > --- > libavcodec/h264dec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) ok thx [...] -- 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. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v2']
From: Takayuki 'January June' Suwa
This adds "-profile[:v] profile_name"-style option IOW.
Thanks for reviewing my poor ugly patch, Mark... and I get back to an original
purpose - forcing OMX to use baseline profile.
(eg. RasPiCam-to-Ustream webcasting w/o additional xcoding)
---
libavcodec/omx.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 16df50e..faa70ae 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
int output_buf_size;
int input_zerocopy;
+int profile;
} OMXCodecContext;
static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
@@ -523,6 +524,20 @@ static av_cold int omx_component_init(AVCodecContext
*avctx, const char *role)
CHECK(err);
avc.nBFrames = 0;
avc.nPFrames = avctx->gop_size - 1;
+switch (s->profile) {
+case FF_PROFILE_H264_BASELINE:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
+break;
+case FF_PROFILE_H264_MAIN:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileMain;
+break;
+case FF_PROFILE_H264_HIGH:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileHigh;
+break;
+}
err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, &avc);
CHECK(err);
}
@@ -884,6 +899,10 @@ static const AVOption options[] = {
{ "omx_libname", "OpenMAX library name", OFFSET(libname),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
{ "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
{ "zerocopy", "Try to avoid copying input frames if possible",
OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "profile", "Set the encoding profile", OFFSET(profile),
AV_OPT_TYPE_INT, { .i64 = 0 },0,
FF_PROFILE_H264_HIGH, VE, "profile" },
+{ "baseline", "", 0,
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, "profile" },
+{ "main", "", 0,
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, "profile" },
+{ "high", "", 0,
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_HIGH }, 0, 0, VE, "profile" },
{ NULL }
};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/dashenc: Only use temporary files when outputting to file protocol
Skips using temporary files when outputting to a protocol other than
"file", which enables dash to output content over network
protocols. The logic has been copied from the HLS format.
---
libavformat/dashenc.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 534fa75..fa56505 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -444,9 +444,15 @@ static int write_manifest(AVFormatContext *s, int final)
AVIOContext *out;
char temp_filename[1024];
int ret, i;
+const char *proto = avio_find_protocol_name(s->filename);
+int use_rename = proto && !strcmp(proto, "file");
+static unsigned int warned_non_file = 0;
AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL, 0);
-snprintf(temp_filename, sizeof(temp_filename), "%s.tmp", s->filename);
+if (!use_rename && !warned_non_file++)
+av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this
may lead to races and temporary partial files\n");
+
+snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" :
"%s", s->filename);
ret = s->io_open(s, &out, temp_filename, AVIO_FLAG_WRITE, NULL);
if (ret < 0) {
av_log(s, AV_LOG_ERROR, "Unable to open %s for writing\n",
temp_filename);
@@ -548,7 +554,11 @@ static int write_manifest(AVFormatContext *s, int final)
avio_printf(out, "\n");
avio_flush(out);
ff_format_io_close(s, &out);
-return avpriv_io_move(temp_filename, s->filename);
+
+if (use_rename)
+return avpriv_io_move(temp_filename, s->filename);
+
+return 0;
}
static int dash_init(AVFormatContext *s)
@@ -796,6 +806,10 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
{
DASHContext *c = s->priv_data;
int i, ret = 0;
+
+const char *proto = avio_find_protocol_name(s->filename);
+int use_rename = proto && !strcmp(proto, "file");
+
int cur_flush_segment_index = 0;
if (stream >= 0)
cur_flush_segment_index = c->streams[stream].segment_index;
@@ -833,7 +847,7 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
if (!c->single_file) {
dash_fill_tmpl_params(filename, sizeof(filename),
c->media_seg_name, i, os->segment_index, os->bit_rate, os->start_pts);
snprintf(full_path, sizeof(full_path), "%s%s", c->dirname,
filename);
-snprintf(temp_path, sizeof(temp_path), "%s.tmp", full_path);
+snprintf(temp_path, sizeof(temp_path), use_rename ? "%s.tmp" :
"%s", full_path);
ret = s->io_open(s, &os->out, temp_path, AVIO_FLAG_WRITE, NULL);
if (ret < 0)
break;
@@ -851,9 +865,12 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
find_index_range(s, full_path, start_pos, &index_length);
} else {
ff_format_io_close(s, &os->out);
-ret = avpriv_io_move(temp_path, full_path);
-if (ret < 0)
-break;
+
+if (use_rename) {
+ret = avpriv_io_move(temp_path, full_path);
+if (ret < 0)
+break;
+}
}
add_segment(os, filename, os->start_pts, os->max_pts - os->start_pts,
start_pos, range_length, index_length);
av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d written
to: %s\n", i, os->segment_index, full_path);
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroska: demux BluRay text subtitles
On Mon, Feb 06, 2017 at 09:41:03AM +0200, Petri Hintukainen wrote: > --- > libavformat/matroska.c | 1 + > 1 file changed, 1 insertion(+) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix chroma positioning for 4:2:0 pixel format
On Mon, Feb 06, 2017 at 05:14:14PM +0200, Maksym Veremeyenko wrote: > Hi, > > Attached patch fixes chroma positioning during scaling interlaced 4:2:0. > > On a first iteration default context value been overwritten by new > value and not been update on next iterations for fields. This mean > that vertical chroma position remain 128 for field#0 and field#1 > instead of *64* and *192*. > > Attached patch use local variable for storing this intermediate > value of chroma vertical position not modifying default context > value. > > -- > Maksym Veremeyenko > > vf_scale.c |9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > 6a3a3966939dd87c45a8e124b0364da30b02728b > 0001-Fix-chroma-positioning-for-4-2-0-pixel-format.patch > From 912ecf538b6b2f7a8df4afdfed2d34052162335c Mon Sep 17 00:00:00 2001 > From: Maksym Veremeyenko > Date: Mon, 6 Feb 2017 17:03:17 +0200 > Subject: [PATCH] Fix chroma positioning for 4:2:0 pixel format applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)
On Tue, Feb 07, 2017 at 12:54:02PM +0100, u-9...@aetey.se wrote: > Hello Michael, > > On Tue, Feb 07, 2017 at 03:09:56AM +0100, Michael Niedermayer wrote: > > > What about the other patches from that series? > > > > > The second one is purely cosmetic (looks useful to me but not much > > > of concern) > > > > I have no oppinion about // vs /**/ comments but in the absence of > > a reason to change them my gut feeling leans toward leaving things > > as they are for "git blame" simplification. > > No objection. > > > > while the third (tiny) one is about correcting an inverted > > > explanation in a comment. > > > > I think the 3rd depends on the 2nd > > No, the third is standalone. > > It was possibly wrong to put them in the same series, but otherwise a > confusion would be probably easy, too. > > > another point which was brought up by jb on IRC and in RL longer ago > > was that ideally the author field in git should contain a name. > > > It may help with contacting one in the far future or with simply > > refering to the author as in > > > who wrote the cinepack optimizations? > > Author: addr-see-the-webs...@aetey.se > > Contact data is not identity even though this fact is ignored in some > widely spread (misled) practices, which the above example illustrates > well. There are actually two separate questions: > > Q: Who wrote the cinepak optimizations? > A: A person known as Rl @ Aetey Global Technologies AB. There is no "Rl" in there git removes that when applying with git am git am ... From: Rl ... git show ... Author: addr-see-the-webs...@aetey.se I dont know why git does that but it does, i retested this as it seemed rather unexpected and odd I can manually override this and force git to use Rl as name so i will do that, but this may be error prone if git fails to keep Rl even after there are commits in the tree with that name. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] libavcodec/cinepak.c: fix a wrong (inverted) misleading comment
On Sun, Jan 29, 2017 at 06:44:59PM +0100, u-9...@aetey.se wrote: > Attaching the new version. > > Regards, > Rune > cinepak.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > def45a2ab19cda70cad0618033a002298cbae056 > 0003-libavcodec-cinepak.c-fix-a-wrong-inverted-misleading.patch > From f2041c0aaa5209e5d52649f741b6ee1dbc7e9021 Mon Sep 17 00:00:00 2001 > From: Rl > Date: Sun, 29 Jan 2017 18:28:25 +0100 > Subject: [PATCH 3/3] libavcodec/cinepak.c: fix a wrong (inverted) misleading > comment applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] imgutils: Document av_image_get_buffer_size()
On Tue, Feb 07, 2017 at 10:01:52AM -0500, Vittorio Giovara wrote: > --- > libavutil/imgutils.h | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h > index 67063a2..ac1bcb8 100644 > --- a/libavutil/imgutils.h > +++ b/libavutil/imgutils.h > @@ -169,7 +169,12 @@ int av_image_fill_arrays(uint8_t *dst_data[4], int > dst_linesize[4], > * Return the size in bytes of the amount of data required to store an > * image with the given parameters. > * > - * @param[in] align the assumed linesize alignment > + * @param pix_fmt the pixel format of the image > + * @param widththe width of the image in pixels > + * @param height the height of the image in pixels > + * @param alignthe assumed linesize alignment > + * @return the size in bytes required for src, a negative error code > + * in case of failure There is no "src" in this function or its documentation > */ > int av_image_get_buffer_size(enum AVPixelFormat pix_fmt, int width, int > height, int align); [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Mark some codecs with threadsafe init as such
On Tue, Feb 07, 2017 at 04:36:38PM +, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis > --- > I wrote this in Nov 2015, and it has resided on my GitHub fork in a branch > since then, since I never ot around to finishing it. I noticed a spike in > interest in the 'feature', so I rebase and am forwarding this, in case it > is of interest. > > During the triage I noted the following codecs need to be properly fixed: >* cavs >* asv >* bink >* ... more ... > > CC me in any reply you feel needs my direct response. > --- > libavcodec/aasc.c | 1 + > libavcodec/aic.c | 1 + > libavcodec/anm.c | 1 + > libavcodec/ansi.c | 1 + > libavcodec/aura.c | 1 + > libavcodec/avrndec.c | 1 + > libavcodec/avs.c | 1 + > libavcodec/avuidec.c | 1 + > libavcodec/bethsoftvideo.c | 1 + > libavcodec/bfi.c | 1 + > libavcodec/bmvvideo.c | 1 + > libavcodec/c93.c | 1 + > libavcodec/cllc.c | 1 + > libavcodec/cyuv.c | 2 ++ > libavcodec/fraps.c | 1 + > libavcodec/lcldec.c| 2 ++ > libavcodec/pngdec.c| 3 ++- > libavcodec/r210dec.c | 3 +++ > libavcodec/utvideodec.c| 1 + > libavcodec/v408dec.c | 2 ++ > libavcodec/vble.c | 1 + > libavcodec/zerocodec.c | 1 + > 22 files changed, 28 insertions(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] imgutils: Document av_image_get_buffer_size()
and the forgotten-CC mail On Tue, Feb 07, 2017 at 11:28:21PM +0100, Michael Niedermayer wrote: > On Tue, Feb 07, 2017 at 10:01:52AM -0500, Vittorio Giovara wrote: > > --- > > libavutil/imgutils.h | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h > > index 67063a2..ac1bcb8 100644 > > --- a/libavutil/imgutils.h > > +++ b/libavutil/imgutils.h > > @@ -169,7 +169,12 @@ int av_image_fill_arrays(uint8_t *dst_data[4], int > > dst_linesize[4], > > * Return the size in bytes of the amount of data required to store an > > * image with the given parameters. > > * > > - * @param[in] align the assumed linesize alignment > > + * @param pix_fmt the pixel format of the image > > + * @param widththe width of the image in pixels > > + * @param height the height of the image in pixels > > + * @param alignthe assumed linesize alignment > > > + * @return the size in bytes required for src, a negative error code > > + * in case of failure > > There is no "src" in this function or its documentation > > > > */ > > int av_image_get_buffer_size(enum AVPixelFormat pix_fmt, int width, int > > height, int align); [...] -- 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
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
Updated to SIZE_MAX. Thank you for your comments.
On Thu, Dec 15, 2016 at 5:23 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 15.12.2016 03:25, James Almer wrote:
> > On 12/14/2016 10:39 PM, Andreas Cadhalpun wrote:
> >> On 15.12.2016 00:34, Matthew Wolenetz wrote:
> >>>
> >>> From fd878457cd55690d4a27d74411b68a30c9fb2313 Mon Sep 17 00:00:00 2001
> >>> From: Matt Wolenetz
> >>> Date: Fri, 2 Dec 2016 18:10:39 -0800
> >>> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in
> mov_read_hdlr
> >>>
> >>> Core of patch is from p...@paulmehta.com
> >>> Reference https://crbug.com/643950
> >>> ---
> >>> libavformat/mov.c | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >>> index 2a69890..7254505 100644
> >>> --- a/libavformat/mov.c
> >>> +++ b/libavformat/mov.c
> >>> @@ -739,6 +739,8 @@ static int mov_read_hdlr(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> >>>
> >>> title_size = atom.size - 24;
> >>> if (title_size > 0) {
> >>> +if (title_size >= UINT_MAX)
> >>
> >> I think this should use SIZE_MAX.
> >
> > title_size is int64_t and SIZE_MAX is UINT64_MAX on x86_64.
>
> Yes, but the argument of av_malloc is size_t.
>
> >>
> >>> +return AVERROR_INVALIDDATA;
> >>> title_str = av_malloc(title_size + 1); /* Add null terminator
> */
>
> So this should cast the argument to size_t to fix the issue on x86_64:
> title_str = av_malloc((size_t)title_size + 1); /* Add null
> terminator */
>
> Best regards,
> Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From 9ce997c0cc31b3609031590b57e64587acc2aa87 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Wed, 14 Dec 2016 15:24:42 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643950
Signed-off-by: Matt Wolenetz
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6fd43a0a4e..4b86e0fd36 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -742,6 +742,8 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb, MOVAtom atom)
title_size = atom.size - 24;
if (title_size > 0) {
+if (title_size >= SIZE_MAX)
+return AVERROR_INVALIDDATA;
title_str = av_malloc(title_size + 1); /* Add null terminator */
if (!title_str)
return AVERROR(ENOMEM);
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
Updated to SIZE_MAX. Thank you for your comments.
On Wed, Dec 14, 2016 at 5:39 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 15.12.2016 00:36, Matthew Wolenetz wrote:
> > From 9d45f272a682b0ea831c20e36f696e15cc0c55fe Mon Sep 17 00:00:00 2001
> > From: Matt Wolenetz
> > Date: Tue, 6 Dec 2016 12:33:08 -0800
> > Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
> >
> > Core of patch is from p...@paulmehta.com
> > Reference https://crbug.com/643951
> > ---
> > libavformat/mov.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 7254505..e506d20 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -4393,6 +4393,8 @@ static int mov_read_uuid(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> > } else if (!memcmp(uuid, uuid_xmp, sizeof(uuid))) {
> > uint8_t *buffer;
> > size_t len = atom.size - sizeof(uuid);
> > +if (len >= UINT_MAX)
>
> This should also use SIZE_MAX.
>
> > +return AVERROR_INVALIDDATA;
> >
> > buffer = av_mallocz(len + 1);
> > if (!buffer) {
>
> Best regards,
> Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From 1763ad5ae340e09081d8f50e867c2702cb5ec61e Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Wed, 14 Dec 2016 15:26:19 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643951
Signed-off-by: Matt Wolenetz
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6fd43a0a4e..93aece510c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4849,6 +4849,8 @@ static int mov_read_uuid(MOVContext *c, AVIOContext *pb, MOVAtom atom)
uint8_t *buffer;
size_t len = atom.size - sizeof(uuid);
if (c->export_xmp) {
+if (len >= SIZE_MAX)
+return AVERROR_INVALIDDATA;
buffer = av_mallocz(len + 1);
if (!buffer) {
return AVERROR(ENOMEM);
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
On 08/02/17 00:09, Matthew Wolenetz wrote:
> From 1763ad5ae340e09081d8f50e867c2702cb5ec61e Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Wed, 14 Dec 2016 15:26:19 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
>
> Core of patch is from p...@paulmehta.com
> Reference https://crbug.com/643951
>
> Signed-off-by: Matt Wolenetz
> ---
> libavformat/mov.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 6fd43a0a4e..93aece510c 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4849,6 +4849,8 @@ static int mov_read_uuid(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> uint8_t *buffer;
> size_t len = atom.size - sizeof(uuid);
> if (c->export_xmp) {
> +if (len >= SIZE_MAX)
> +return AVERROR_INVALIDDATA;
> buffer = av_mallocz(len + 1);
> if (!buffer) {
> return AVERROR(ENOMEM);
> --
> 2.11.0.483.g087da7b7c-goog
I don't know precisely what this is trying to do, but it doesn't look very
sensible to me (I can't see any context because your reference link is blocked
behind some sort of login page).
Since SIZE_MAX is the largest size_t (i.e. -1), only len == SIZE_MAX can
satisfy the test so it is actually "if (atom.size == sizeof(uuid) - 1)", and if
atom.size is something less than sizeof(uuid) - 1 then you are passing a silly
value to av_mallocz().
I admit that it doesn't actually invoke undefined behaviour in this case, but
the general rules for overflow checks to avoid any surprises are:
(a) Always put the check before the operation which might overflow.
(b) Always express the check in a way which cannot itself overflow.
So, I think you would be better off writing:
size_t len;
if (atom.size < sizeof(uuid))
return AVERROR_INVALIDDATA;
len = atom.size - sizeof(uuid);
(If there is additional information hidden behind the link which renders my
comments invalid then please do share it directly.)
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
On Tue, Feb 07, 2017 at 03:46:02PM -0800, Matthew Wolenetz wrote:
> Updated to SIZE_MAX. Thank you for your comments.
>
>
> On Thu, Dec 15, 2016 at 5:23 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
> > On 15.12.2016 03:25, James Almer wrote:
> > > On 12/14/2016 10:39 PM, Andreas Cadhalpun wrote:
> > >> On 15.12.2016 00:34, Matthew Wolenetz wrote:
> > >>>
> > >>> From fd878457cd55690d4a27d74411b68a30c9fb2313 Mon Sep 17 00:00:00 2001
> > >>> From: Matt Wolenetz
> > >>> Date: Fri, 2 Dec 2016 18:10:39 -0800
> > >>> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in
> > mov_read_hdlr
> > >>>
> > >>> Core of patch is from p...@paulmehta.com
> > >>> Reference https://crbug.com/643950
> > >>> ---
> > >>> libavformat/mov.c | 2 ++
> > >>> 1 file changed, 2 insertions(+)
> > >>>
> > >>> diff --git a/libavformat/mov.c b/libavformat/mov.c
> > >>> index 2a69890..7254505 100644
> > >>> --- a/libavformat/mov.c
> > >>> +++ b/libavformat/mov.c
> > >>> @@ -739,6 +739,8 @@ static int mov_read_hdlr(MOVContext *c,
> > AVIOContext *pb, MOVAtom atom)
> > >>>
> > >>> title_size = atom.size - 24;
> > >>> if (title_size > 0) {
> > >>> +if (title_size >= UINT_MAX)
> > >>
> > >> I think this should use SIZE_MAX.
> > >
> > > title_size is int64_t and SIZE_MAX is UINT64_MAX on x86_64.
> >
> > Yes, but the argument of av_malloc is size_t.
> >
> > >>
> > >>> +return AVERROR_INVALIDDATA;
> > >>> title_str = av_malloc(title_size + 1); /* Add null terminator
> > */
> >
> > So this should cast the argument to size_t to fix the issue on x86_64:
> > title_str = av_malloc((size_t)title_size + 1); /* Add null
> > terminator */
> >
> > Best regards,
> > Andreas
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> mov.c |2 ++
> 1 file changed, 2 insertions(+)
> 7141b8dfebcafab0db3b8f3f332068916718b093
> 643950-lavf-mov.c-Avoid-heap-allocation-wrap-in-mov_read_hd.patch
> From 9ce997c0cc31b3609031590b57e64587acc2aa87 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Wed, 14 Dec 2016 15:24:42 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
>
> Core of patch is from p...@paulmehta.com
> Reference https://crbug.com/643950
>
> Signed-off-by: Matt Wolenetz
> ---
> libavformat/mov.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 6fd43a0a4e..4b86e0fd36 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -742,6 +742,8 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb,
> MOVAtom atom)
>
> title_size = atom.size - 24;
> if (title_size > 0) {
> +if (title_size >= SIZE_MAX)
> +return AVERROR_INVALIDDATA;
I know this was suggested here but the code below clearly doesnt
support title_size > INT_MAX, so the check should be for that
Also from the point of view of sanity, this is a string identifing
the handler if iam not mistaken,
if that is megabytes or more there is something strange going on,
so bailing out on 2gb should not be a problem
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
On Wed, Feb 08, 2017 at 01:25:58AM +, Mark Thompson wrote:
> On 08/02/17 00:09, Matthew Wolenetz wrote:
> > From 1763ad5ae340e09081d8f50e867c2702cb5ec61e Mon Sep 17 00:00:00 2001
> > From: Matt Wolenetz
> > Date: Wed, 14 Dec 2016 15:26:19 -0800
> > Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
> >
> > Core of patch is from p...@paulmehta.com
> > Reference https://crbug.com/643951
> >
> > Signed-off-by: Matt Wolenetz
> > ---
> > libavformat/mov.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 6fd43a0a4e..93aece510c 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -4849,6 +4849,8 @@ static int mov_read_uuid(MOVContext *c, AVIOContext
> > *pb, MOVAtom atom)
> > uint8_t *buffer;
> > size_t len = atom.size - sizeof(uuid);
> > if (c->export_xmp) {
> > +if (len >= SIZE_MAX)
> > +return AVERROR_INVALIDDATA;
> > buffer = av_mallocz(len + 1);
> > if (!buffer) {
> > return AVERROR(ENOMEM);
> > --
> > 2.11.0.483.g087da7b7c-goog
>
> I don't know precisely what this is trying to do, but it doesn't look very
> sensible to me (I can't see any context because your reference link is
> blocked behind some sort of login page).
>
> Since SIZE_MAX is the largest size_t (i.e. -1), only len == SIZE_MAX can
> satisfy the test so it is actually "if (atom.size == sizeof(uuid) - 1)", and
> if atom.size is something less than sizeof(uuid) - 1 then you are passing a
> silly value to av_mallocz().
>
> I admit that it doesn't actually invoke undefined behaviour in this case, but
> the general rules for overflow checks to avoid any surprises are:
> (a) Always put the check before the operation which might overflow.
> (b) Always express the check in a way which cannot itself overflow.
>
> So, I think you would be better off writing:
>
> size_t len;
> if (atom.size < sizeof(uuid))
> return AVERROR_INVALIDDATA;
> len = atom.size - sizeof(uuid);
that alone is not enough
ill push a fix which appears to be sufficent, dont want to leave either
of these open while its discussed whats the best solution
if theres some issue in my fixes dont hesitate to improve or replace,
ill go to bed after testing and pushing my fixes
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: deprecate hls_wrap option
When user use the hls_wrap, there have many problem:
1. some platform refersh the old but usefull segment
2. CDN(Content Delivery Network) Deliver HLS not friendly
The hls_wrap is used to wrap segments for use little space,
now user can use hls_list_size and hls_flags delete_segments
instead it.
Signed-off-by: Steven Liu
---
doc/muxers.texi | 5 ++---
libavformat/hlsenc.c | 24
libavformat/version.h | 4
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb875a4..c00e296 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -441,9 +441,8 @@ parameters. Values containing @code{:} special characters
must be
escaped.
@item hls_wrap @var{wrap}
-Set the number after which the segment filename number (the number
-specified in each segment file) wraps. If set to 0 the number will be
-never wrapped. Default value is 0.
+This is a deprecated option, you can use @code {hls_list_size}
+and @code{hls_flags delete_segments} instead it
This option is useful to avoid to fill the disk with many segment
files, and limits the maximum number of segment files written to disk
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 17d4fe4..736c949 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -101,7 +101,9 @@ typedef struct HLSContext {
float time;// Set by a private option.
float init_time; // Set by a private option.
int max_nb_segments; // Set by a private option.
+#ifdef FF_API_HLS_WRAP
int wrap; // Set by a private option.
+#endif
uint32_t flags;// enum HLSFlags
uint32_t pl_type; // enum PlaylistType
char *segment_filename;
@@ -566,7 +568,11 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
hls->initial_prog_date_time += en->duration;
hls->segments = en->next;
if (en && hls->flags & HLS_DELETE_SEGMENTS &&
+#ifdef FF_API_HLS_WRAP
!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
+#else
+!(hls->flags & HLS_SINGLE_FILE)) {
+#endif
en->next = hls->old_segments;
hls->old_segments = en;
if ((ret = hls_delete_old_segments(hls)) < 0)
@@ -834,7 +840,11 @@ static int hls_start(AVFormatContext *s)
sizeof(vtt_oc->filename));
} else if (c->max_seg_size > 0) {
if (replace_int_data_in_filename(oc->filename, sizeof(oc->filename),
+#ifdef FF_API_HLS_WRAP
c->basename, 'd', c->wrap ? c->sequence % c->wrap : c->sequence) <
1) {
+#else
+c->basename, 'd', c->sequence) < 1) {
+#endif
av_log(oc, AV_LOG_ERROR, "Invalid segment filename template
'%s', you can try to use -use_localtime 1 with it\n", c->basename);
return AVERROR(EINVAL);
}
@@ -853,7 +863,11 @@ static int hls_start(AVFormatContext *s)
if (!filename)
return AVERROR(ENOMEM);
if (replace_int_data_in_filename(oc->filename,
sizeof(oc->filename),
+#ifdef FF_API_HLS_WRAP
filename, 'd', c->wrap ? c->sequence % c->wrap :
c->sequence) < 1) {
+#else
+filename, 'd', c->sequence) < 1) {
+#endif
av_log(c, AV_LOG_ERROR,
"Invalid second level segment filename template
'%s', "
"you can try to remove second_level_segment_index
flag\n",
@@ -910,13 +924,21 @@ static int hls_start(AVFormatContext *s)
av_free(fn_copy);
}
} else if (replace_int_data_in_filename(oc->filename,
sizeof(oc->filename),
+#ifdef FF_API_HLS_WRAP
c->basename, 'd', c->wrap ? c->sequence % c->wrap :
c->sequence) < 1) {
+#else
+ c->basename, 'd', c->sequence) < 1) {
+#endif
av_log(oc, AV_LOG_ERROR, "Invalid segment filename template '%s'
you can try to use -use_localtime 1 with it\n", c->basename);
return AVERROR(EINVAL);
}
if( c->vtt_basename) {
if (replace_int_data_in_filename(vtt_oc->filename,
sizeof(vtt_oc->filename),
+#ifdef FF_API_HLS_WRAP
c->vtt_basename, 'd', c->wrap ? c->sequence % c->wrap :
c->sequence) < 1) {
+#else
+c->vtt_basename, 'd', c->sequence) < 1) {
+#endif
av_log(vtt_oc, AV_LOG_ERROR, "Invalid segment filename
template '%s'\n", c->vtt_basename);
return AVERROR(EINVAL);
}
@@ -1421,7 +1443,9 @@ static const AVOption options[] = {
{"hls_list_size", "set maximum number of playlist entries",
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, E},
{"hls_ts_options","set hls mpegts list of options for the container format
used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str = NULL},
0, 0,E},
{"hls_vtt_options","set hls vtt list o
Re: [FFmpeg-devel] [PATCH 1/3] cmdutils_opencl: fix resource_leak cid 1396852
2017-01-12 3:29 GMT+08:00 Michael Niedermayer :
> On Tue, Jan 10, 2017 at 07:44:32PM +0800, Steven Liu wrote:
> > CID: 1396852
> > check the devices_list alloc status,
> > and release the devices_list when alloc devices error
> >
> > Signed-off-by: Steven Liu
> > ---
> > cmdutils_opencl.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmdutils_opencl.c b/cmdutils_opencl.c
> > index dd21344..5bbc8dc 100644
> > --- a/cmdutils_opencl.c
> > +++ b/cmdutils_opencl.c
> > @@ -220,15 +220,20 @@ int opt_opencl_bench(void *optctx, const char
> *opt, const char *arg)
> > OpenCLDeviceBenchmark *devices = NULL;
> > cl_platform_id platform;
> >
> > -av_opencl_get_device_list(&device_list);
> > +if (av_opencl_get_device_list(&device_list) < 0) {
> > +return AVERROR(ENOMEM);
> > +}
>
> The error code from av_opencl_get_device_list() should be forwarded
>
> thx
>
Hi
Looks good to me
Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The educated differ from the uneducated as much as the living from the
> dead. -- Aristotle
>
> ___
> 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] Efficiently support several output pixel formats in Cinepak decoder
On Tue, Feb 7, 2017 at 10:54 AM, Ronald S. Bultje wrote: > Hi, > > On Tue, Feb 7, 2017 at 12:04 PM, wrote: > >> cinepak, rgb2419.7 (via the fast bilinear swscaler) >> cinepak, internal rgb565 6.0 > > > The reason that your decoder-integrated colorspace convertor is so much > faster than swscale is because swscale is converting internally to yuv420p > using a scaling filter, and then back to rgb565 using another scaling > filter. This is "easily" solved by adding a direct (possibly > x86-simd-accelerated) rgb24-to-rgb565 converter into > libswscale/swscale_unscaled.c, which would likely have nearly identical > performance to what you're seeing here. Possibly even faster, because > you're allowing for simd optimizations. There is already a rgb24-to-rgb565 path, but it does not get used by default because of the needsDither check in ff_get_unscaled_swscale(). If the scaling algorithm is set to fast_bilinear, needsDither is ignored and the RGB24 to RGB16 converter is used. (In either case, no actual scaling is performed, so the scaling algorithm is irrelevant aside from selecting dithering.) Looking at the mplayer docs, this is probably equivalent to '-sws 0'. e.g. ffmpeg -i -f null -c rawvideo -pix_fmt rgb565le -sws_flags fast_bilinear /dev/null Using matrixbench_mpeg2.mpg (720x567) encoded with ffmpeg into Cinepak using default settings, decoding on an i5 3570K, 3.4 GHz: bicubic (default): ~24x realtime fast_bilinear: ~65x realtime patch w/rgb565 override:~154x realtime As far as I can tell, this patch doesn't do any dithering for RGB565, so the fast_bilinear (non-dithering) swscale converter is a fair comparison. -- Daniel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.
Hey is there an update on the status of the patch? Any other requested changes? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder
On Tue, Feb 07, 2017 at 12:54:23PM -0500, Ronald S. Bultje wrote: > On Tue, Feb 7, 2017 at 12:04 PM, wrote: > > > cinepak, rgb2419.7 (via the fast bilinear swscaler) > > cinepak, internal rgb565 6.0 > > > The reason that your decoder-integrated colorspace convertor is so much > faster than swscale is because swscale is converting internally to yuv420p > using a scaling filter, and then back to rgb565 using another scaling > filter. (If this indeed happens, this does not sound exactly efficient, nor is a conversion to yuv420p lossless itself, IOW a shame?) > This is "easily" solved by adding a direct (possibly > x86-simd-accelerated) rgb24-to-rgb565 converter into > libswscale/swscale_unscaled.c, which would likely have nearly identical > performance to what you're seeing here. Possibly even faster, because > you're allowing for simd optimizations. This unfortunately can not come near an identical performance because it would have to work on several times more data (frame vs codebook). Besides that, there would be at least an extra copy operation over each frame, even if the conversion itself would be indefinitely fast. Generally: I value layered design as much as you do, but it introduces limitations. For comparison, an example from a different domain, but well known: ZFS. It shortcut several "design layers" in the storage subsystem which allowed a lot of improvement and did not render ZFS unmaintainable. The shortcuts I add (not introduce, just add to the present ones) are of exactly the same nature as a specialized converter in libswscale. I just add them in a place where they are several times more efficient (the amount of data to handle). Cinepak is hardly going to make an impact similar to ZFS now :) but it has in fact been very big before. In certain aspects, by the original design, it is still superior to virtualy anything else at hand. With the proposed optimization we get the best out of its virtues. It would be a waste to ignore the possibility. Regards, Rune ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/vaapi_encode: fix PoC negative issue
From e37b2598d372b790c0a496c7b750802a1aa102be Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Wed, 8 Feb 2017 15:25:18 +0800
Subject: [PATCH] lavc/vaapi_encode: fix PoC negative issue.
the issue occurs when setting a large b frames number with option "bf",
it results from hard coding the sps.log2_max_pic_order_cnt_lsb_minus4 with
0/8 in h264/hevc vaapi encoder.
Signed-off-by: Jun Zhao
Signed-off-by: Yi A Wang
---
libavcodec/vaapi_encode_h264.c | 7 +++
libavcodec/vaapi_encode_h265.c | 7 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 00d8e6a..946f8b9 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -784,6 +784,8 @@ static int
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
VAAPIEncodeH264Context*priv = ctx->priv_data;
VAAPIEncodeH264MiscSequenceParams *mseq = &priv->misc_sequence_params;
int i;
+int max_delta_poc;
+int log2_max_poc_lsb = 4;
{
vseq->seq_parameter_set_id = 0;
@@ -801,6 +803,11 @@ static int
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
vseq->seq_fields.bits.log2_max_frame_num_minus4 = 4;
vseq->seq_fields.bits.pic_order_cnt_type = 0;
+max_delta_poc = (avctx->max_b_frames + 2) * 2;
+while ((1 << log2_max_poc_lsb) <= max_delta_poc * 2)
+log2_max_poc_lsb++;
+vseq->seq_fields.bits.log2_max_pic_order_cnt_lsb_minus4 =
log2_max_poc_lsb - 4;
+
if (avctx->width != ctx->surface_width ||
avctx->height != ctx->surface_height) {
vseq->frame_cropping_flag = 1;
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index c5589ed..2fb8a3f 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -786,6 +786,8 @@ static int
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
VAAPIEncodeH265Context*priv = ctx->priv_data;
VAAPIEncodeH265MiscSequenceParams *mseq = &priv->misc_sequence_params;
int i;
+int max_delta_poc;
+int log2_max_poc_lsb = 8;
{
// general_profile_space == 0.
@@ -895,7 +897,10 @@ static int
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
mseq->general_frame_only_constraint_flag = 1;
mseq->general_inbld_flag = 0;
-mseq->log2_max_pic_order_cnt_lsb_minus4 = 8;
+max_delta_poc = (avctx->max_b_frames + 2) * 2;
+while ((1 << log2_max_poc_lsb) <= max_delta_poc)
+log2_max_poc_lsb++;
+mseq->log2_max_pic_order_cnt_lsb_minus4 = log2_max_poc_lsb - 4;
mseq->vps_sub_layer_ordering_info_present_flag = 0;
mseq->vps_max_dec_pic_buffering_minus1[0] = (avctx->max_b_frames > 0)
+ 1;
mseq->vps_max_num_reorder_pics[0] = (avctx->max_b_frames > 0);
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
