Re: [FFmpeg-devel] [PATCH v3] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video in AVI
On 02/02/2016 08:38 AM, Mats Peterson wrote: The file doesn't use rgb555le pixel format per se of course, but it will be played back with the assumption that it is rgb555le, while the video data is in fact 1 bpp. My bad. The output nut file will use a RGB[15] codec tag alright. Totally incorrect, in any case. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video in AVI
On Mon, Feb 01, 2016 at 19:15:37 +0100, wm4 wrote: > Can you just try to wait with your reply 30-60mins, instead of > constantly spamming the mailing list with follow ups? I think people are starting/continuing to ignore him, due to the constant monologs. I look at my mailbox in threaded view in the morning and just collapse all the long chains of Mats -> Mats -> Mats -> ... ;-) (Just sayin', 'cause he's doin' it again.) M. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video in AVI
On 02/02/2016 09:55 AM, Moritz Barsnick wrote: On Mon, Feb 01, 2016 at 19:15:37 +0100, wm4 wrote: Can you just try to wait with your reply 30-60mins, instead of constantly spamming the mailing list with follow ups? I think people are starting/continuing to ignore him, due to the constant monologs. I look at my mailbox in threaded view in the morning and just collapse all the long chains of Mats -> Mats -> Mats -> ... ;-) (Just sayin', 'cause he's doin' it again.) Yes, because it's justified. I'm not the person who sits an hour finding out things to write about. And there is something called threads, but it seems not everyone has heard of it. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dca: add new fate tests based on the dcadec-samples test suite
On Tue, Feb 2, 2016 at 5:10 AM, James Almer wrote:
> On 2/1/2016 8:55 PM, Hendrik Leppkes wrote:
>> +define FATE_DCADEC_LOSSLESS_SUITE
>> +FATE_DCADEC_LOSSLESS += fate-dca-$(1) fate-dca-$(1)-dmix_2
>> fate-dca-$(1)-dmix_6
>> +fate-dca-$(1): CMD = framemd5 -i
>> $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -f $(2)
>> +fate-dca-$(1)-dmix_2: CMD = framemd5 -request_channel_layout 0x3 -i
>> $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -f $(2)
>> +fate-dca-$(1)-dmix_6: CMD = framemd5 -request_channel_layout 0x60f -i
>> $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -f $(2)
>
> change -f to -c:a, and s{16,24}le below to pcm_s{16,24}le.
> framemd5 adds "-f framemd5 -" at the end of the command line overwriting the
> one you pass here, making ffmpeg default to pcm_s16le output.
>
Fixed locally, thanks.
Somehow I thought it would work like md5, but guess not!
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dca: add new fate tests based on the dcadec-samples test suite
On Tue, Feb 2, 2016 at 3:05 AM, James Almer wrote: > On 2/1/2016 7:51 PM, Hendrik Leppkes wrote: >> On Mon, Feb 1, 2016 at 11:29 PM, James Almer wrote: >>> On 2/1/2016 7:01 PM, Hendrik Leppkes wrote: --- tests/fate/dca.mak| 72 +++ tests/ref/fate/dca-xll_51_16_192_768_0| 1 + tests/ref/fate/dca-xll_51_16_192_768_1| 1 + tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2 | 1 + tests/ref/fate/dca-xll_51_24_48_768 | 1 + tests/ref/fate/dca-xll_51_24_48_none | 1 + tests/ref/fate/dca-xll_71_24_48_768_0 | 1 + tests/ref/fate/dca-xll_71_24_48_768_0-dmix_2 | 1 + tests/ref/fate/dca-xll_71_24_48_768_0-dmix_6 | 1 + tests/ref/fate/dca-xll_71_24_48_768_1 | 1 + tests/ref/fate/dca-xll_71_24_48_768_1-dmix_2 | 1 + tests/ref/fate/dca-xll_71_24_48_768_1-dmix_6 | 1 + tests/ref/fate/dca-xll_71_24_96_768 | 1 + tests/ref/fate/dca-xll_x96_51_24_96_1509 | 1 + tests/ref/fate/dca-xll_xch_61_24_48_768 | 1 + 15 files changed, 86 insertions(+) create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_0 create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_1 create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2 create mode 100644 tests/ref/fate/dca-xll_51_24_48_768 create mode 100644 tests/ref/fate/dca-xll_51_24_48_none create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_0 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_0-dmix_2 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_0-dmix_6 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_1 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_1-dmix_2 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_1-dmix_6 create mode 100644 tests/ref/fate/dca-xll_71_24_96_768 create mode 100644 tests/ref/fate/dca-xll_x96_51_24_96_1509 create mode 100644 tests/ref/fate/dca-xll_xch_61_24_48_768 diff --git a/tests/fate/dca.mak b/tests/fate/dca.mak index d8c1117..78d2f33 100644 --- a/tests/fate/dca.mak +++ b/tests/fate/dca.mak @@ -1,3 +1,75 @@ +# dcadec test samples +DCADEC_SUITE_LOSSLESS_16 = xll_51_16_192_768_0\ + xll_51_16_192_768_1\ + +DCADEC_SUITE_LOSSLESS_24 = xll_51_24_48_768 \ + xll_51_24_48_none \ + xll_71_24_48_768_0 \ + xll_71_24_48_768_1 \ + xll_71_24_96_768 \ + xll_x96_51_24_96_1509 \ + xll_xch_61_24_48_768 \ + +DCADEC_SUITE_LOSSY = core_51_24_48_768_0\ + core_51_24_48_768_1\ + x96_51_24_96_1509 \ + x96_xch_61_24_96_3840 \ + x96_xxch_71_24_96_3840 \ + xbr_51_24_48_3840 \ + xbr_xch_61_24_48_3840 \ + xbr_xxch_71_24_48_3840 \ + xch_61_24_48_768 \ + xxch_71_24_48_2046 \ + +define FATE_DCADEC_LOSSLESS_SUITE +FATE_DCADEC_LOSSLESS += fate-dca-$(1) +fate-dca-$(1): CMD = md5 -i $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -f $(2) >>> >>> Unlike the existing xll sample, all these new ones have six frames max, so >>> you >>> could use framecrc or framemd5 instead. >> >> Suppose that might make debugging easier in the future if something breaks. >> >>> +endef + +define FATE_DCADEC_LOSSY_SUITE +FATE_DCADEC_LOSSY += fate-dca-$(1) +fate-dca-$(1): CMD = pcm -i $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd +fate-dca-$(1): CMP = oneoff >>> >>> Should be ok assuming converting to s16 before doing the comparison is >>> acceptable. >>> I say this because the samples are 24bit if decoded using the fixed >>> codepath, and >>> once we create the reference pcm files and add them to the fate suit, we'll >>> be >>> stuck with them. >> >> The decoder works in float by default, and all other float codecs use >> this kind of test. > > mp3 fate tests use f32 mode, for example. Besides, most of those decoders > output > 16bit audio when not using floats. > >> Not sure how much precision there actually is in the dca float signal >> for lossy, but if someone thinks its worse it we could try to use >> tiny_psnr in float or s32 mode (it doesn't do s24) > > tiny_psnr doesn't seem to do s32 either, only f32. How hard would it be to add > it, or s24? If anything I think we should make it test f32 since thats the native outp
Re: [FFmpeg-devel] [PATCH] dca: add new fate tests based on the dcadec-samples test suite
On Tue, Feb 2, 2016 at 10:13 AM, Hendrik Leppkes wrote: >>> >>> The decoder works in float by default, and all other float codecs use >>> this kind of test. >> >> mp3 fate tests use f32 mode, for example. Besides, most of those decoders >> output >> 16bit audio when not using floats. >> >>> Not sure how much precision there actually is in the dca float signal >>> for lossy, but if someone thinks its worse it we could try to use >>> tiny_psnr in float or s32 mode (it doesn't do s24) >> >> tiny_psnr doesn't seem to do s32 either, only f32. How hard would it be to >> add >> it, or s24? > > If anything I think we should make it test f32 since thats the native > output mode, or stick to the usual s16 as converted by swr. > Using the bitexact fixed point code path for those samples to get s24 > out of the decoder would leave the float path entirely untested. > >> >>> Would require more careful tuning of the test though, as the precision >>> on different systems will definitely differ then. >> >> Changing the tests to make them use f32 seems to need a FUZZ of at least 7. > > mp3 uses a fuzz of 17, so its likely going to require higher fuzz > values on different systems. > Will only find out after seeing it fail on FATE on a bunch of systems though. > >> >> I'd like foo86 to chime in and give his opinion in the matter, but in any >> case >> this is not a blocker so if you think s16 is fine then go ahead. > > We can also go with f32, its not going to be "worse" than a s16 test, > just need to be prepared to update the fuzz values in the first couple > days. > I did some testing on the fuzz values, and 9 is the lowest that makes everything pass on my system. References generated with cpuflags 0 and x87 fpu, and tested against various combinations of increasing flags to determine the fuzz. So do we just "try" with 9, and increase it where it fails? New patch coming after this mail. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] dca: add new fate tests based on the dcadec-samples test suite
--- tests/fate/dca.mak | 64 + tests/ref/fate/dca-xll_51_16_192_768_0 | 11 + tests/ref/fate/dca-xll_51_16_192_768_0-dmix_2 | 11 + tests/ref/fate/dca-xll_51_16_192_768_0-dmix_6 | 11 + tests/ref/fate/dca-xll_51_16_192_768_1 | 11 + tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2 | 11 + tests/ref/fate/dca-xll_51_16_192_768_1-dmix_6 | 11 + tests/ref/fate/dca-xll_51_24_48_768 | 11 + tests/ref/fate/dca-xll_51_24_48_768-dmix_2 | 11 + tests/ref/fate/dca-xll_51_24_48_768-dmix_6 | 11 + tests/ref/fate/dca-xll_51_24_48_none| 8 tests/ref/fate/dca-xll_51_24_48_none-dmix_2 | 8 tests/ref/fate/dca-xll_51_24_48_none-dmix_6 | 8 tests/ref/fate/dca-xll_71_24_48_768_0 | 11 + tests/ref/fate/dca-xll_71_24_48_768_0-dmix_2| 11 + tests/ref/fate/dca-xll_71_24_48_768_0-dmix_6| 11 + tests/ref/fate/dca-xll_71_24_48_768_1 | 11 + tests/ref/fate/dca-xll_71_24_48_768_1-dmix_2| 11 + tests/ref/fate/dca-xll_71_24_48_768_1-dmix_6| 11 + tests/ref/fate/dca-xll_71_24_96_768 | 11 + tests/ref/fate/dca-xll_71_24_96_768-dmix_2 | 11 + tests/ref/fate/dca-xll_71_24_96_768-dmix_6 | 11 + tests/ref/fate/dca-xll_x96_51_24_96_1509| 11 + tests/ref/fate/dca-xll_x96_51_24_96_1509-dmix_2 | 11 + tests/ref/fate/dca-xll_x96_51_24_96_1509-dmix_6 | 11 + tests/ref/fate/dca-xll_xch_61_24_48_768 | 11 + tests/ref/fate/dca-xll_xch_61_24_48_768-dmix_2 | 11 + tests/ref/fate/dca-xll_xch_61_24_48_768-dmix_6 | 11 + 28 files changed, 352 insertions(+) create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_0 create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_0-dmix_2 create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_0-dmix_6 create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_1 create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2 create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_1-dmix_6 create mode 100644 tests/ref/fate/dca-xll_51_24_48_768 create mode 100644 tests/ref/fate/dca-xll_51_24_48_768-dmix_2 create mode 100644 tests/ref/fate/dca-xll_51_24_48_768-dmix_6 create mode 100644 tests/ref/fate/dca-xll_51_24_48_none create mode 100644 tests/ref/fate/dca-xll_51_24_48_none-dmix_2 create mode 100644 tests/ref/fate/dca-xll_51_24_48_none-dmix_6 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_0 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_0-dmix_2 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_0-dmix_6 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_1 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_1-dmix_2 create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_1-dmix_6 create mode 100644 tests/ref/fate/dca-xll_71_24_96_768 create mode 100644 tests/ref/fate/dca-xll_71_24_96_768-dmix_2 create mode 100644 tests/ref/fate/dca-xll_71_24_96_768-dmix_6 create mode 100644 tests/ref/fate/dca-xll_x96_51_24_96_1509 create mode 100644 tests/ref/fate/dca-xll_x96_51_24_96_1509-dmix_2 create mode 100644 tests/ref/fate/dca-xll_x96_51_24_96_1509-dmix_6 create mode 100644 tests/ref/fate/dca-xll_xch_61_24_48_768 create mode 100644 tests/ref/fate/dca-xll_xch_61_24_48_768-dmix_2 create mode 100644 tests/ref/fate/dca-xll_xch_61_24_48_768-dmix_6 diff --git a/tests/fate/dca.mak b/tests/fate/dca.mak index d8c1117..0790799 100644 --- a/tests/fate/dca.mak +++ b/tests/fate/dca.mak @@ -1,3 +1,67 @@ +# dcadec test samples +DCADEC_SUITE_LOSSLESS_16 = xll_51_16_192_768_0\ + xll_51_16_192_768_1\ + +DCADEC_SUITE_LOSSLESS_24 = xll_51_24_48_768 \ + xll_51_24_48_none \ + xll_71_24_48_768_0 \ + xll_71_24_48_768_1 \ + xll_71_24_96_768 \ + xll_x96_51_24_96_1509 \ + xll_xch_61_24_48_768 \ + +DCADEC_SUITE_LOSSY = core_51_24_48_768_0\ + core_51_24_48_768_1\ + x96_51_24_96_1509 \ + x96_xch_61_24_96_3840 \ + x96_xxch_71_24_96_3840 \ + xbr_51_24_48_3840 \ + xbr_xch_61_24_48_3840 \ + xbr_xxch_71_24_48_3840 \ + xch_61_24_48_768 \ + xxch_71_24_48_2046 \ + +define FATE_DCADEC_LOSSLESS_SUITE +FATE_DCADEC_LOSSLESS += fate-dca-$(1) fate-dca-$(1)-dmix_2 fate-dca-$(1)-dmix_6 +fate-dca-$(1): CMD = framemd5 -i $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -c:a pcm_$(2) +fate-dca-$(1)-dmix_2: CMD = framemd5 -request_channel_layout 0x3 -i $(TARGET_SAMPLES)
Re: [FFmpeg-devel] [PATCH 2/2] dca: add new fate tests based on the dcadec-samples test suite
On Tue, Feb 02, 2016 at 12:53:29AM +0100, Hendrik Leppkes wrote: > On Tue, Feb 2, 2016 at 12:24 AM, Michael Niedermayer > wrote: > > On Mon, Feb 01, 2016 at 09:34:12PM +0100, Hendrik Leppkes wrote: > >> On Mon, Feb 1, 2016 at 9:22 PM, Hendrik Leppkes > >> wrote: > >> > On Mon, Feb 1, 2016 at 9:20 PM, Hendrik Leppkes > >> > wrote: > >> >> --- > >> >> tests/fate/dca.mak | 41 > >> >> > >> >> tests/ref/fate/dca-xll_51_16_192_768_0 | 1 + > >> >> tests/ref/fate/dca-xll_51_16_192_768_1 | 1 + > >> >> tests/ref/fate/dca-xll_51_24_48_768 | 1 + > >> >> tests/ref/fate/dca-xll_51_24_48_none | 1 + > >> >> tests/ref/fate/dca-xll_71_24_48_768_0| 1 + > >> >> tests/ref/fate/dca-xll_71_24_48_768_1| 1 + > >> >> tests/ref/fate/dca-xll_71_24_96_768 | 1 + > >> >> tests/ref/fate/dca-xll_x96_51_24_96_1509 | 1 + > >> >> tests/ref/fate/dca-xll_xch_61_24_48_768 | 1 + > >> >> 10 files changed, 50 insertions(+) > >> >> create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_0 > >> >> create mode 100644 tests/ref/fate/dca-xll_51_16_192_768_1 > >> >> create mode 100644 tests/ref/fate/dca-xll_51_24_48_768 > >> >> create mode 100644 tests/ref/fate/dca-xll_51_24_48_none > >> >> create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_0 > >> >> create mode 100644 tests/ref/fate/dca-xll_71_24_48_768_1 > >> >> create mode 100644 tests/ref/fate/dca-xll_71_24_96_768 > >> >> create mode 100644 tests/ref/fate/dca-xll_x96_51_24_96_1509 > >> >> create mode 100644 tests/ref/fate/dca-xll_xch_61_24_48_768 > >> >> > >> > > >> > As an extra info, all new samples and the pcm references for the lossy > >> > tests are in total only 1MB, so quite tiny for 19 new fate tests that > >> > greatly increase coverage. > >> > > >> > >> For even more coverage, could also add downmix tests using all the > >> existing samples (down to 6 and 2 respectively). > > > > consideing this is just 1-2mb or something, iam in favor of it > > didnt test though > > > > Adding a bunch of identical pcm files seems rather wasteful, so I'm > currently favoring the approach of simply testing both downmix modes > on all of the XLL files which only have a md5 check and not a > reference file, and testing downmix on a few lossy samples where its > actually doing something. sure, i didnt realize there would be duplicates ... > That should still cover a wide variety of code paths. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)
Hi,
as a motus operandi for this review, I have no time for a proper one,
or at least not fitting with John's timeframe. I'll try to close as
many pending discussions, and would prefer if someone else completed
the review/validation/commit.
2016-01-22 19:33 GMT+01:00 John Cox :
> Fair enough - though given that your slowdowns are almost certainly
> cache-related the whole may be quite different from the sum of the
> parts.
True, they don't always translate to anything noticeable, but that's
the best tool we have to objectively decide.
>>cosmetics?
>
> I renamed the variable, because c_idx can have values 0..2 and c_idx_nz
> is a boolean with 0..1 and in the rewrite of the inc var it is important
> that we are using the _nz variant so having the var named appropriately
> seemed sensible.
I don't really mind mixing some form of cosmetics (=supposedly without
code generation consequences) although other people prefer splitting
for easier review and regression testing.
This is not a blocking item for me, just that finding the most
appropriate commit would be nice.
>>I suppose branch prediction could help here, but less likely than for
>>get_cabac_sig_coeff_flag_idxs.
>>
>>Also for this and some others: why inline over av_always_inline?
> No particularly good reason for this one - though for any fn that might
> be called from multiple places there is a strong argument for just
> "inline" as it allows the compiler to make a judgment call based on how
> big L1 cache is and how bad the call penalty.
Anyway, those kinds of micro-optimizations I'm suggesting need more
testing (sequences, platforms), so let's roll with this.
>>AV_WN64 of 0x0101010101010101ULL, or even a memset, as it would be
>>inlined by the compiler, given its size, and done the best possible
>>way.
>
> levels is int *, not char *
Ok, sorry, then 0x00010001ULL. But you can ignore this, it'll
probably make no difference outside of a micro-benchmark.
>>Saturation, could be a separate patch, with which I would be ok.
btw and iirc, a comment indicated assumptions on what is a "legit"
(instead of conforming ) bitstream/coeffs, making a conscious
decision.
I know Ronald, ffvp9's author, specifically decided to handle
equivalent cases in bitstreams (hint) from Argon Designs. I have no
opinion, but others might.
>>Related to but not strictly bypass ?
>
> Not bypass per se, more the general optimisation of abs_level_remaining
> - it is pulled out because I had a slightly better arm asm version of
> the fn. So it could go in that patch, but this allows other asm to
> override it if they so desire.
What I meant: would better be there than in another commit.
>>Doing:
>>if (get_cabac(c, state0 + ctx_map[n]))
>>*p++ = n;
>>while (--n != 0) {
>>if (get_cabac(c, state0 + ctx_map[n]))
>>*p++ = n;
>>}
>>is most likely faster, probably also on arm, if the branch prediction is good.
>
> Not convinced. That will increase code size (as get_cabac will inline)
> which can be pure poison as you have found out with USE_N_END_1.
That's 300B, not 1.5KB. And I *know* it can help, just not on all
platforms and sequences. The same decision was made for ffh264's
equivalent, iirc.
But this would need more validated results, so let's ignore that discussion.
>>boolean? (not sure)
> I saw no booleans anywhere in the rest of this code so assumed they were
> (at best) deprecated. But if there is an official ffmpeg boolean then
> that is what it should be.
Sorry for the imprecision, ffmpeg doesn't have a boolean type. I meant
this to be possibly split as its own kind of modification, not fitting
with anything else. Or not, this shouldn't be a blocking item.
>>So we decided to have #define USE_N_END_1 ARCH_ARM. As said in another
>>mail, there's a 10-20% loss for the codeblock.
>>
>>USE_BY22_DIV also strangely provides no benefit.
> Slightly surprised by that, but DIV is going to produce smaller code so
> should be preferred on general grounds as it puts off cache disasters.
There maybe pessimization (spelling?) there, if the compiler doesn't
manage to generate the idiv + picking edx for the shifted result.
I haven't checked the disassembled code.
BR,
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)
Hi
On Tue, 2 Feb 2016 12:52:15 +0100, you wrote:
>Hi,
>
>as a motus operandi for this review, I have no time for a proper one,
>or at least not fitting with John's timeframe. I'll try to close as
>many pending discussions, and would prefer if someone else completed
>the review/validation/commit.
Thanks
>2016-01-22 19:33 GMT+01:00 John Cox :
>> Fair enough - though given that your slowdowns are almost certainly
>> cache-related the whole may be quite different from the sum of the
>> parts.
>
>True, they don't always translate to anything noticeable, but that's
>the best tool we have to objectively decide.
Yes, but it isn't always a good one. I have spent substantial time in
the past optimising TI DSP based codecs and it was not uncommon that
some patches would make life slightly slower until enough of them were
applied and then the whole thing suddenly gained a jump in speed.
Either way I'm not averse to splitting stuff up and, at least on ARM,
none of the patches caused a slowdown.
>>>cosmetics?
>>
>> I renamed the variable, because c_idx can have values 0..2 and c_idx_nz
>> is a boolean with 0..1 and in the rewrite of the inc var it is important
>> that we are using the _nz variant so having the var named appropriately
>> seemed sensible.
>
>I don't really mind mixing some form of cosmetics (=supposedly without
>code generation consequences) although other people prefer splitting
>for easier review and regression testing.
>
>This is not a blocking item for me, just that finding the most
>appropriate commit would be nice.
My point was that I changed the inputs to that fn and so I changed the
vars name to make the point clearer - it should be part of the c_idx_nz
patch.
>>>I suppose branch prediction could help here, but less likely than for
>>>get_cabac_sig_coeff_flag_idxs.
>>>
>>>Also for this and some others: why inline over av_always_inline?
>> No particularly good reason for this one - though for any fn that might
>> be called from multiple places there is a strong argument for just
>> "inline" as it allows the compiler to make a judgment call based on how
>> big L1 cache is and how bad the call penalty.
>
>Anyway, those kinds of micro-optimizations I'm suggesting need more
>testing (sequences, platforms), so let's roll with this.
>
>>>AV_WN64 of 0x0101010101010101ULL, or even a memset, as it would be
>>>inlined by the compiler, given its size, and done the best possible
>>>way.
>>
>> levels is int *, not char *
>
>Ok, sorry, then 0x00010001ULL. But you can ignore this, it'll
>probably make no difference outside of a micro-benchmark.
My experience with compilers is that this is the sort of thing that they
can and will do off their own bat. (Certainly MS C has been unrolling
this sort of memset loop for the past two decades and I'd be stunned if
gcc doesn't too),
>>>Saturation, could be a separate patch, with which I would be ok.
>
>btw and iirc, a comment indicated assumptions on what is a "legit"
>(instead of conforming ) bitstream/coeffs, making a conscious
>decision.
>
>I know Ronald, ffvp9's author, specifically decided to handle
>equivalent cases in bitstreams (hint) from Argon Designs. I have no
>opinion, but others might.
>
>>>Related to but not strictly bypass ?
>>
>> Not bypass per se, more the general optimisation of abs_level_remaining
>> - it is pulled out because I had a slightly better arm asm version of
>> the fn. So it could go in that patch, but this allows other asm to
>> override it if they so desire.
>
>What I meant: would better be there than in another commit.
>
>>>Doing:
>>>if (get_cabac(c, state0 + ctx_map[n]))
>>>*p++ = n;
>>>while (--n != 0) {
>>>if (get_cabac(c, state0 + ctx_map[n]))
>>>*p++ = n;
>>>}
>>>is most likely faster, probably also on arm, if the branch prediction is
>>>good.
>>
>> Not convinced. That will increase code size (as get_cabac will inline)
>> which can be pure poison as you have found out with USE_N_END_1.
>
>That's 300B, not 1.5KB. And I *know* it can help, just not on all
>platforms and sequences. The same decision was made for ffh264's
>equivalent, iirc.
I'll have to take your word for it but it seems very strange to me that
fn(x);
while(cond)
fn(x);
is faster than
do {
fn(x);
} while (cond);
I guess that it might be a branch prediction thing, but the second form
uses no more conditions and the first and is shorter. (And the compiler
always has the option of unrolling the 2nd form into the 1st.)
>But this would need more validated results, so let's ignore that discussion.
Yup - despite what I said above if you can show that first form is
objectively faster than the first on all platforms then you should use
it...
>>>boolean? (not sure)
>> I saw no booleans anywhere in the rest of this code so assumed they were
>> (at best) deprecated. But if there is an official ffmpeg boolean then
>> that is what it should be.
>
>Sorry for the imprecision, ffmpeg doesn't have a boolean type. I m
[FFmpeg-devel] [PATCH 1/4] diradec: split tables away to a separate diractab file
Preparing for next commits which add a VC-2 encoder.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/Makefile | 2 +-
libavcodec/diracdec.c | 79 ---
2 files changed, 7 insertions(+), 74 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a89fb11..941057b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -227,7 +227,7 @@ OBJS-$(CONFIG_DCA_DECODER) += dcadec.o dca.o
dcadata.o\
dcadsp.o dcadct.o synth_filter.o
OBJS-$(CONFIG_DCA_ENCODER) += dcaenc.o dca.o dcadata.o
OBJS-$(CONFIG_DDS_DECODER) += dds.o
-OBJS-$(CONFIG_DIRAC_DECODER) += diracdec.o dirac.o diracdsp.o \
+OBJS-$(CONFIG_DIRAC_DECODER) += diracdec.o dirac.o diracdsp.o
diractab.o \
dirac_arith.o mpeg12data.o
dirac_dwt.o
OBJS-$(CONFIG_DFA_DECODER) += dfa.o
OBJS-$(CONFIG_DNXHD_DECODER) += dnxhddec.o dnxhddata.o
diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index ca44e7b..0312dde 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -243,73 +243,6 @@ enum dirac_subband {
subband_nb,
};
-static const uint8_t default_qmat[][4][4] = {
-{ { 5, 3, 3, 0}, { 0, 4, 4, 1}, { 0, 5, 5, 2}, { 0, 6, 6, 3} },
-{ { 4, 2, 2, 0}, { 0, 4, 4, 2}, { 0, 5, 5, 3}, { 0, 7, 7, 5} },
-{ { 5, 3, 3, 0}, { 0, 4, 4, 1}, { 0, 5, 5, 2}, { 0, 6, 6, 3} },
-{ { 8, 4, 4, 0}, { 0, 4, 4, 0}, { 0, 4, 4, 0}, { 0, 4, 4, 0} },
-{ { 8, 4, 4, 0}, { 0, 4, 4, 0}, { 0, 4, 4, 0}, { 0, 4, 4, 0} },
-{ { 0, 4, 4, 8}, { 0, 8, 8, 12}, { 0, 13, 13, 17}, { 0, 17, 17, 21} },
-{ { 3, 1, 1, 0}, { 0, 4, 4, 2}, { 0, 6, 6, 5}, { 0, 9, 9, 7} },
-};
-
-static const int32_t qscale_tab[116] = {
- 4, 5, 6, 7, 8,10,11,
13,
-16,19,23,27,32,38,45,
54,
-64,76,91, 108, 128, 152, 181,
215,
- 256, 304, 362, 431, 512, 609, 724,
861,
- 1024, 1218, 1448, 1722, 2048, 2435, 2896,
3444,
- 4096, 4871, 5793, 6889, 8192, 9742, 11585,
13777,
- 16384, 19484, 23170, 27554, 32768, 38968, 46341,
55109,
- 65536, 77936, 92682,110218,131072,155872,185364,
220436,
-262144,311744,370728,440872,524288,623487,741455,
881744,
- 1048576, 1246974, 1482910, 1763488, 2097152, 2493948, 2965821,
3526975,
- 4194304, 4987896, 5931642, 7053950, 8388608, 9975792, 11863283,
14107901,
- 16777216, 19951585, 23726566, 28215802, 33554432, 39903169, 47453133,
56431603,
- 67108864, 79806339, 94906266, 112863206, 134217728, 159612677, 189812531,
225726413,
- 268435456, 319225354, 379625062, 451452825, 536870912, 638450708, 759250125,
902905651,
-1073741824,1276901417,1518500250,1805811301,/*2147483648,2553802834,3037000500,3611622603,
-4294967296*/
-};
-
-static const int32_t qoffset_intra_tab[120] = {
-1, 2, 3, 4, 4, 5, 6,
7,
-8,10,12,14,16,19,23,
27,
- 32,38,46,54,64,76,91,
108,
- 128, 152, 181, 216, 256, 305, 362,
431,
- 512, 609, 724, 861, 1024, 1218, 1448,
1722,
- 2048, 2436, 2897, 3445, 4096, 4871, 5793,
6889,
- 8192, 9742, 11585, 13777, 16384, 19484, 23171,
27555,
-32768, 38968, 46341, 55109, 65536, 77936, 92682,
110218,
- 131072,155872,185364,220436,262144,311744,370728,
440872,
- 524288,623487,741455,881744, 1048576, 1246974, 1482911,
1763488,
- 2097152, 2493948, 2965821, 3526975, 4194304, 4987896, 5931642,
7053951,
- 8388608, 9975793, 11863283, 14107901, 16777216, 19951585, 23726567,
28215802,
- 33554432, 39903170, 47453133, 56431603, 67108864, 79806339, 94906266,
112863207,
-134217728, 159612677, 189812531, 225726413, 268435456, 319225354, 379625063,
451452826,
-536870912, 638450709, 759250125,
902905651,1073741824,1276901417,1518500250,1805811302,
-/*2147483648, 2553802834, 3037000500, 3611622603, 4294967296,*/
-};
-
-static const int qoffset_inter_tab[122] = {
-1, 2, 2, 3, 3, 4, 4,
5,
-6, 7, 9,10,12,14,17,
20,
-
[FFmpeg-devel] [PATCH 0/4] Add a native SMPTE VC-2 encoder
This series of commits adds a native SMPTE VC-2 encoder capable of encoding files using the HQ profile. Rostislav Pehlivanov (4): diradec: split tables away to a separate diractab file diracdec: move the MAX_DWT_LEVELS macro to dirac.h avcodec: add a native SMPTE VC-2 encoder avformat: add vc2 as an allowed rawenc Dirac extension libavcodec/Makefile |3 +- libavcodec/allcodecs.c |1 + libavcodec/dirac.h | 11 + libavcodec/diracdec.c | 91 +--- libavcodec/vc2enc.c | 1154 +++ libavcodec/vc2enc_dwt.c | 234 ++ libavcodec/vc2enc_dwt.h | 54 +++ libavformat/rawenc.c|2 +- 8 files changed, 1464 insertions(+), 86 deletions(-) create mode 100644 libavcodec/vc2enc.c create mode 100644 libavcodec/vc2enc_dwt.c create mode 100644 libavcodec/vc2enc_dwt.h -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avformat: add vc2 as an allowed rawenc Dirac extension
Signed-off-by: Rostislav Pehlivanov
---
libavformat/rawenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 9474ed1..358ee4e 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -115,7 +115,7 @@ AVOutputFormat ff_data_muxer = {
AVOutputFormat ff_dirac_muxer = {
.name = "dirac",
.long_name = NULL_IF_CONFIG_SMALL("raw Dirac"),
-.extensions= "drc",
+.extensions= "drc,vc2",
.audio_codec = AV_CODEC_ID_NONE,
.video_codec = AV_CODEC_ID_DIRAC,
.write_header = force_one_stream,
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] diracdec: move the MAX_DWT_LEVELS macro to dirac.h
Used by the VC-2 encoder. Signed-off-by: Rostislav Pehlivanov --- libavcodec/dirac.h| 11 +++ libavcodec/diracdec.c | 12 +--- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/libavcodec/dirac.h b/libavcodec/dirac.h index cb80fdc..e6d9d34 100644 --- a/libavcodec/dirac.h +++ b/libavcodec/dirac.h @@ -34,6 +34,17 @@ #include "avcodec.h" /** + * The spec limits the number of wavelet decompositions to 4 for both + * level 1 (VC-2) and 128 (long-gop default). + * 5 decompositions is the maximum before >16-bit buffers are needed. + * Schroedinger allows this for DD 9,7 and 13,7 wavelets only, limiting + * the others to 4 decompositions (or 3 for the fidelity filter). + * + * We use this instead of MAX_DECOMPOSITIONS to save some memory. + */ +#define MAX_DWT_LEVELS 5 + +/** * Parse code values: * * Dirac Specification -> diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c index 0312dde..de7daf3 100644 --- a/libavcodec/diracdec.c +++ b/libavcodec/diracdec.c @@ -37,21 +37,11 @@ #include "mpegvideoencdsp.h" #include "dirac_dwt.h" #include "dirac.h" +#include "diractab.h" #include "diracdsp.h" #include "videodsp.h" /** - * The spec limits the number of wavelet decompositions to 4 for both - * level 1 (VC-2) and 128 (long-gop default). - * 5 decompositions is the maximum before >16-bit buffers are needed. - * Schroedinger allows this for DD 9,7 and 13,7 wavelets only, limiting - * the others to 4 decompositions (or 3 for the fidelity filter). - * - * We use this instead of MAX_DECOMPOSITIONS to save some memory. - */ -#define MAX_DWT_LEVELS 5 - -/** * The spec limits this to 3 for frame coding, but in practice can be as high as 6 */ #define MAX_REFERENCE_FRAMES 8 -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avcodec: add a native SMPTE VC-2 encoder
A new revision of the 'Dirac' encoder previously submitted. Changes from previous version: - Rename to vc2 - Fix an out of array bound read on setting quantization matrices Original commit message: This commit adds a new encoder capable of creating SMPTE Dirac/VC-2 HQ profile files. Dirac is a wavelet based codec created by the BBC a little more than 10 years ago. Since then, wavelets have mostly gone out of style as they did not provide adequate encoding gains at lower bitrates. Dirac was a fully featured video codec equipped with perceptual masking, support for most popular pixel formats, interlacing, overlapped-block motion compensation, and other features. It found new life after being stripped of various features and standardized as the VC-2 codec by the SMPTE with an extra profile, the HQ profile that this encoder supports, added. The HQ profile was based off of the Low-Delay profile previously existing in Dirac. The profile forbids DC prediction and arithmetic coding to focus on high performance and low delay at higher bitrates. The standard bitrates for this profile vary but generally 1:4 compression is expected (~525 Mbps vs the 2200 Mbps for uncompressed 1080p50). The codec only supports I-frames, hence the high bitrates. The structure of this encoder is simple: do a DWT transform on the entire image, split it into multiple slices (specified by the user) and encode them in parallel. All of the slices are of the same size, making rate control and threading very trivial. Although only in C, this encoder is capable of 30 frames per second on an 4 core 8 threads Ivy Bridge. A lookup table is used to encode most of the coefficients. No code was used from the GSoC encoder from 2007 except for the 2 transform functions in diracenc_transforms.c. All other code was written from scratch. This encoder outperforms any other encoders in quality, usability and in features. Other existing implementations do not support 4 level transforms or 64x64 blocks (slices), which greatly increase compression. As previously said, the codec is meant for broadcasting, hence support for non-broadcasting image widths, heights, bit depths, aspect ratios, etc. are limited by the "level". Although this codec supports a few chroma subsamplings (420, 422, 444), signalling those is generally outside the specifications of the level used (3) and the reference decoder will outright refuse to read any image with such a flag signalled (it only supports 1920x1080 yuv422p10). However, most implementations will happily read files with alternate dimensions, framerates and formats signalled. Therefore, in order to encode files other than 1080p50 yuv422p10le, you need to provide an "-strict -2" argument to the command line. The FFmpeg decoder will happily read any files made with non-standard parameters, dimensions and subsamplings, and so will other implementations. IMO this should be "-strict -1", but I'll leave that up for discussion. There are still plenty of stuff to implement, for instance 5 more wavelet transforms are still in the specs and supported by the decoder. Signed-off-by: Rostislav Pehlivanov --- libavcodec/Makefile |1 + libavcodec/allcodecs.c |1 + libavcodec/vc2enc.c | 1154 +++ libavcodec/vc2enc_dwt.c | 234 ++ libavcodec/vc2enc_dwt.h | 54 +++ 5 files changed, 1444 insertions(+) create mode 100644 libavcodec/vc2enc.c create mode 100644 libavcodec/vc2enc_dwt.c create mode 100644 libavcodec/vc2enc_dwt.h diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 941057b..f6a4fbb 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -543,6 +543,7 @@ OBJS-$(CONFIG_VC1_DECODER) += vc1dec.o vc1_block.o vc1_loopfilter.o wmv2dsp.o OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec_vc1.o +OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o diractab.o OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index c7c1af5..2097db0 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -336,6 +336,7 @@ void avcodec_register_all(void) REGISTER_DECODER(VC1IMAGE, vc1image); REGISTER_DECODER(VC1_MMAL, vc1_mmal); REGISTER_DECODER(VC1_QSV, vc1_qsv); +REGISTER_ENCODER(VC2, vc2); REGISTER_DECODER(VCR1, vcr1); REGISTER_DECODER(VMDVIDEO, vmdvideo); REGISTER_DECODER(VMNC, vmnc); diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c new file mode 100644 index 000..afafe42 --- /dev/null +++ b/libavcodec/vc2enc.c @@ -0,0 +1,1154 @@ +/* + * Copyright (C) 2016 Open Broadcast Systems Ltd. + * Author(C) 2016 Rostislav Pehlivanov + * + * Th
Re: [FFmpeg-devel] [PATCH 1/4] diradec: split tables away to a separate diractab file
On Tue, Feb 02, 2016 at 12:35:27PM +, Rostislav Pehlivanov wrote: > Preparing for next commits which add a VC-2 encoder. > > Signed-off-by: Rostislav Pehlivanov > --- > libavcodec/Makefile | 2 +- > libavcodec/diracdec.c | 79 > --- > 2 files changed, 7 insertions(+), 74 deletions(-) did you forget to add the diractab file ? [] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avcodec: add a native SMPTE VC-2 encoder
On Tue, Feb 02, 2016 at 12:35:29PM +, Rostislav Pehlivanov wrote: > A new revision of the 'Dirac' encoder previously submitted. > > Changes from previous version: > - Rename to vc2 > - Fix an out of array bound read on setting quantization matrices > > Original commit message: > > This commit adds a new encoder capable of creating SMPTE Dirac/VC-2 HQ > profile files. > > Dirac is a wavelet based codec created by the BBC a little more than 10 > years ago. Since then, wavelets have mostly gone out of style as they > did not provide adequate encoding gains at lower bitrates. Dirac was a > fully featured video codec equipped with perceptual masking, support for > most popular pixel formats, interlacing, overlapped-block motion > compensation, and other features. It found new life after being stripped > of various features and standardized as the VC-2 codec by the SMPTE with > an extra profile, the HQ profile that this encoder supports, added. > > The HQ profile was based off of the Low-Delay profile previously > existing in Dirac. The profile forbids DC prediction and arithmetic > coding to focus on high performance and low delay at higher bitrates. > The standard bitrates for this profile vary but generally 1:4 > compression is expected (~525 Mbps vs the 2200 Mbps for uncompressed > 1080p50). The codec only supports I-frames, hence the high bitrates. > > The structure of this encoder is simple: do a DWT transform on the > entire image, split it into multiple slices (specified by the user) and > encode them in parallel. All of the slices are of the same size, making > rate control and threading very trivial. Although only in C, this > encoder > is capable of 30 frames per second on an 4 core 8 threads Ivy Bridge. > A lookup table is used to encode most of the coefficients. > > No code was used from the GSoC encoder from 2007 except for the 2 > transform functions in diracenc_transforms.c. All other code was written > from scratch. > > This encoder outperforms any other encoders in quality, usability and in > features. Other existing implementations do not support 4 level > transforms or 64x64 blocks (slices), which greatly increase compression. > > As previously said, the codec is meant for broadcasting, hence support > for non-broadcasting image widths, heights, bit depths, aspect ratios, > etc. are limited by the "level". Although this codec supports a few > chroma subsamplings (420, 422, 444), signalling those is generally > outside the specifications of the level used (3) and the reference > decoder will outright refuse to read any image with such a flag > signalled (it only supports 1920x1080 yuv422p10). However, most > implementations will happily read files with alternate dimensions, > framerates and formats signalled. > > Therefore, in order to encode files other than 1080p50 yuv422p10le, you > need to provide an "-strict -2" argument to the command line. The FFmpeg > decoder will happily read any files made with non-standard parameters, > dimensions and subsamplings, and so will other implementations. IMO this > should be "-strict -1", but I'll leave that up for discussion. > > There are still plenty of stuff to implement, for instance 5 more > wavelet transforms are still in the specs and supported by the decoder. > > Signed-off-by: Rostislav Pehlivanov > --- > libavcodec/Makefile |1 + > libavcodec/allcodecs.c |1 + > libavcodec/vc2enc.c | 1154 > +++ > libavcodec/vc2enc_dwt.c | 234 ++ > libavcodec/vc2enc_dwt.h | 54 +++ > 5 files changed, 1444 insertions(+) > create mode 100644 libavcodec/vc2enc.c > create mode 100644 libavcodec/vc2enc_dwt.c > create mode 100644 libavcodec/vc2enc_dwt.h > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index 941057b..f6a4fbb 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -543,6 +543,7 @@ OBJS-$(CONFIG_VC1_DECODER) += vc1dec.o > vc1_block.o vc1_loopfilter.o >wmv2dsp.o > OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o > OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec_vc1.o > +OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o diractab.o > OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o > OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o > OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c > index c7c1af5..2097db0 100644 > --- a/libavcodec/allcodecs.c > +++ b/libavcodec/allcodecs.c > @@ -336,6 +336,7 @@ void avcodec_register_all(void) > REGISTER_DECODER(VC1IMAGE, vc1image); > REGISTER_DECODER(VC1_MMAL, vc1_mmal); > REGISTER_DECODER(VC1_QSV, vc1_qsv); > +REGISTER_ENCODER(VC2, vc2); > REGISTER_DECODER(VCR1, vcr1); > REGISTER_DECODER(VMDVIDEO, vmdvideo); > REGISTER_DECODER(VMNC, vmnc
Re: [FFmpeg-devel] [PATCH 1/4] diradec: split tables away to a separate diractab file
On 2 February 2016 at 13:32, Michael Niedermayer
wrote:
>
> did you forget to add the diractab file ?
>
>
Ah, I did.
Correct patch attached.
From dbbe6e72fdc0ca04f4806a1b9c13ead4b563a488 Mon Sep 17 00:00:00 2001
From: Rostislav Pehlivanov
Date: Tue, 2 Feb 2016 14:24:57 +
Subject: [PATCH v2] diradec: split tables away to a separate diractab file
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/Makefile | 2 +-
libavcodec/diracdec.c | 79 -
libavcodec/diractab.c | 89 +++
libavcodec/diractab.h | 41
4 files changed, 137 insertions(+), 74 deletions(-)
create mode 100644 libavcodec/diractab.c
create mode 100644 libavcodec/diractab.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a89fb11..941057b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -227,7 +227,7 @@ OBJS-$(CONFIG_DCA_DECODER) += dcadec.o dca.o dcadata.o\
dcadsp.o dcadct.o synth_filter.o
OBJS-$(CONFIG_DCA_ENCODER) += dcaenc.o dca.o dcadata.o
OBJS-$(CONFIG_DDS_DECODER) += dds.o
-OBJS-$(CONFIG_DIRAC_DECODER) += diracdec.o dirac.o diracdsp.o \
+OBJS-$(CONFIG_DIRAC_DECODER) += diracdec.o dirac.o diracdsp.o diractab.o \
dirac_arith.o mpeg12data.o dirac_dwt.o
OBJS-$(CONFIG_DFA_DECODER) += dfa.o
OBJS-$(CONFIG_DNXHD_DECODER) += dnxhddec.o dnxhddata.o
diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index ca44e7b..0312dde 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -243,73 +243,6 @@ enum dirac_subband {
subband_nb,
};
-static const uint8_t default_qmat[][4][4] = {
-{ { 5, 3, 3, 0}, { 0, 4, 4, 1}, { 0, 5, 5, 2}, { 0, 6, 6, 3} },
-{ { 4, 2, 2, 0}, { 0, 4, 4, 2}, { 0, 5, 5, 3}, { 0, 7, 7, 5} },
-{ { 5, 3, 3, 0}, { 0, 4, 4, 1}, { 0, 5, 5, 2}, { 0, 6, 6, 3} },
-{ { 8, 4, 4, 0}, { 0, 4, 4, 0}, { 0, 4, 4, 0}, { 0, 4, 4, 0} },
-{ { 8, 4, 4, 0}, { 0, 4, 4, 0}, { 0, 4, 4, 0}, { 0, 4, 4, 0} },
-{ { 0, 4, 4, 8}, { 0, 8, 8, 12}, { 0, 13, 13, 17}, { 0, 17, 17, 21} },
-{ { 3, 1, 1, 0}, { 0, 4, 4, 2}, { 0, 6, 6, 5}, { 0, 9, 9, 7} },
-};
-
-static const int32_t qscale_tab[116] = {
- 4, 5, 6, 7, 8,10,11,13,
-16,19,23,27,32,38,45,54,
-64,76,91, 108, 128, 152, 181, 215,
- 256, 304, 362, 431, 512, 609, 724, 861,
- 1024, 1218, 1448, 1722, 2048, 2435, 2896, 3444,
- 4096, 4871, 5793, 6889, 8192, 9742, 11585, 13777,
- 16384, 19484, 23170, 27554, 32768, 38968, 46341, 55109,
- 65536, 77936, 92682,110218,131072,155872,185364,220436,
-262144,311744,370728,440872,524288,623487,741455,881744,
- 1048576, 1246974, 1482910, 1763488, 2097152, 2493948, 2965821, 3526975,
- 4194304, 4987896, 5931642, 7053950, 8388608, 9975792, 11863283, 14107901,
- 16777216, 19951585, 23726566, 28215802, 33554432, 39903169, 47453133, 56431603,
- 67108864, 79806339, 94906266, 112863206, 134217728, 159612677, 189812531, 225726413,
- 268435456, 319225354, 379625062, 451452825, 536870912, 638450708, 759250125, 902905651,
-1073741824,1276901417,1518500250,1805811301,/*2147483648,2553802834,3037000500,3611622603,
-4294967296*/
-};
-
-static const int32_t qoffset_intra_tab[120] = {
-1, 2, 3, 4, 4, 5, 6, 7,
-8,10,12,14,16,19,23,27,
- 32,38,46,54,64,76,91, 108,
- 128, 152, 181, 216, 256, 305, 362, 431,
- 512, 609, 724, 861, 1024, 1218, 1448, 1722,
- 2048, 2436, 2897, 3445, 4096, 4871, 5793, 6889,
- 8192, 9742, 11585, 13777, 16384, 19484, 23171, 27555,
-32768, 38968, 46341, 55109, 65536, 77936, 92682,110218,
- 131072,155872,185364,220436,262144,311744,370728,440872,
- 524288,623487,741455,881744, 1048576, 1246974, 1482911, 1763488,
- 2097152, 2493948, 2965821, 3526975, 4194304, 4987896, 5931642, 7053951,
- 8388608, 9975793, 11863283, 14107901, 16777216, 19951585, 23726567, 28215802,
- 33554432, 39903170, 47453133, 56431603, 67108864, 79806339, 94906266, 112
Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.
On Mon, Feb 01, 2016 at 12:11:10PM -0800, Neil Birkbeck wrote:
> Please see updated patch.
>
> On Mon, Jan 25, 2016 at 11:39 PM, Neil Birkbeck
> wrote:
> > I guess png is another example; 10 is the denominator for the 32-bit
> > integer:
> > https://github.com/FFmpeg/FFmpeg/blob/b58cfa616c169c90166938608e7135cdab5820e0/libavcodec/pngenc.c#L290
> >
> > In the standards, the primaries and white point coords are usually only
> > referenced in 2-4 significant figures (ISO/IEC 23001-8:2013(E) has them all
> > in one doc). The display primaries can be different from these, but I don't
> > think you'd see them measured with any more precision (more precision is
> > unlikely to matter for this metadata anyway).
> >
> > It seems that most are in favor of AVRational, so I'll change the avutil
> > struct float internal fields to rational.
> >
> >
> >
> >
> >
> > On Mon, Jan 25, 2016 at 1:43 PM, Hendrik Leppkes
> > wrote:
> >>
> >> On Mon, Jan 25, 2016 at 10:37 PM, Michael Niedermayer
> >> wrote:
> >> > On Fri, Jan 22, 2016 at 02:54:21PM -0800, Neil Birkbeck wrote:
> >> >> Hmm. I don't have a good idea of how likely it is for this conversion
> >> >> to
> >> >> float (by dividing a constant) to not be bit-exact on different
> >> >> architectures (compilers?) when there should not be any other math
> >> >> transforming the metadata (other than the conversion back to the
> >> >> integer
> >> >> coding for cases like hevc, which for a given architecture is possible
> >> >> without loss). The fact that this could happen at all does make it
> >> >> annoying
> >> >> in terms of bit-exact test expectations across arch, and this is the
> >> >> main
> >> >> concern, right? (for this type of metadata, it is really a hint to
> >> >> TVs/algorithms, and some will ignore it altogether)
> >> >
> >> > bitexactness is one concern, also theres the issue with what is ideally
> >> > correct.
> >> > that is what are the ideal values dictated by various standards
> >> > that hardware (cammeras, ...) aim at ?
> >> > are these rational or float or what can represent them better ?
> >> >
> >>
> >> Both HEVC and the HDMI Info Frames use fixed-point integers (the same
> >> scales too, apparently), I do not know of the formats anything else
> >> uses.
> >> Maybe we should be using AVRationals?
> >>
> >> I would argue that MKV storing floats is a terrible idea, and someone
> >> should bonk them over the head and store fixed point as well.
> >>
> >> - Hendrik
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> hevc.c | 46 ++
> hevc.h |7 +++
> hevc_sei.c | 22 ++
> version.h |2 +-
> 4 files changed, 76 insertions(+), 1 deletion(-)
> a1660d647add89f41e8ed85f8bc26eb4fb36379b
> 0001-lavc-hevc-Parse-SEI_TYPE_MASTERING_DISPLAY_INFO-and-.patch
> From 345db2caf7cac5c0acfb74501b6db9bd57e66f7d Mon Sep 17 00:00:00 2001
> From: Neil Birkbeck
> Date: Thu, 21 Jan 2016 10:56:50 -0800
> Subject: [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate
> content into the AVMasteringDisplayMetadata side data.
>
> Add support for parsing SEI_TYPE_MASTERING_DISPLAY_INFO and propagate
> contents into
> the AVMasteringDisplayMetadata side data. Primaries are ordered in RGB order
> and
> the values are converted to rationals ([0,1] for CEI 1931 Chroma coords,
> and cd/m^2 for luma).
>
> Signed-off-by: Neil Birkbeck
> ---
> libavcodec/hevc.c | 46 ++
> libavcodec/hevc.h | 7 +++
> libavcodec/hevc_sei.c | 22 ++
> libavcodec/version.h | 2 +-
> 4 files changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
> index c245d3b..e475f94 100644
> --- a/libavcodec/hevc.c
> +++ b/libavcodec/hevc.c
> @@ -28,6 +28,7 @@
> #include "libavutil/common.h"
> #include "libavutil/display.h"
> #include "libavutil/internal.h"
> +#include "libavutil/mastering_display_metadata.h"
> #include "libavutil/md5.h"
> #include "libavutil/opt.h"
> #include "libavutil/pixdesc.h"
> @@ -2580,6 +2581,51 @@ static int set_side_data(HEVCContext *s)
> s->sei_hflip, s->sei_vflip);
> }
>
> +if (s->sei_mastering_display_info_present) {
> +// HEVC uses a g,b,r ordering, which we convert to a more natural
> r,g,b
> +const int mapping[3] = {2, 0, 1};
> +const int chroma_den = 5;
> +const int luma_den = 1;
> +int i;
> +AVMasteringDisplayMetadata *metadata =
> +av_mastering_display_metadata_create_side_data(out);
> +if (!metadata)
> +return AVERROR(ENOMEM);
> +
> +for (i = 0; i < 3; i++) {
> +const int j = mapping[i];
> +metadata->display_primaries[i][0].num =
> s->display_primaries[j][
Re: [FFmpeg-devel] [PATCH] dca: add new fate tests based on the dcadec-samples test suite
On 2/2/2016 6:13 AM, Hendrik Leppkes wrote: >> tiny_psnr doesn't seem to do s32 either, only f32. How hard would it be to >> add >> it, or s24? > > If anything I think we should make it test f32 since thats the native > output mode, or stick to the usual s16 as converted by swr. > Using the bitexact fixed point code path for those samples to get s24 > out of the decoder would leave the float path entirely untested. > I didn't mean using bitexact fixed point decoding, just adding s24/32 support to tiny_psnr and use that, which should behave the same way as s16 (dca decodes as float, swr converts to int, tiny_psnr compares that). But in any case f32 is ok. >> >>> Would require more careful tuning of the test though, as the precision >>> on different systems will definitely differ then. >> >> Changing the tests to make them use f32 seems to need a FUZZ of at least 7. > > mp3 uses a fuzz of 17, so its likely going to require higher fuzz > values on different systems. > Will only find out after seeing it fail on FATE on a bunch of systems though. > >> >> I'd like foo86 to chime in and give his opinion in the matter, but in any >> case >> this is not a blocker so if you think s16 is fine then go ahead. > > We can also go with f32, its not going to be "worse" than a s16 test, > just need to be prepared to update the fuzz values in the first couple > days. It should be better at best or the same at worst, assuming we don't go too lax with the FUZZ value. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dca: add new fate tests based on the dcadec-samples test suite
On 2/2/2016 7:36 AM, Hendrik Leppkes wrote: > diff --git a/tests/fate/dca.mak b/tests/fate/dca.mak > index d8c1117..0790799 100644 > --- a/tests/fate/dca.mak > +++ b/tests/fate/dca.mak > @@ -1,3 +1,67 @@ > +# dcadec test samples > +DCADEC_SUITE_LOSSLESS_16 = xll_51_16_192_768_0\ > + xll_51_16_192_768_1\ > + > +DCADEC_SUITE_LOSSLESS_24 = xll_51_24_48_768 \ > + xll_51_24_48_none \ > + xll_71_24_48_768_0 \ > + xll_71_24_48_768_1 \ > + xll_71_24_96_768 \ > + xll_x96_51_24_96_1509 \ > + xll_xch_61_24_48_768 \ > + > +DCADEC_SUITE_LOSSY = core_51_24_48_768_0\ > + core_51_24_48_768_1\ > + x96_51_24_96_1509 \ > + x96_xch_61_24_96_3840 \ > + x96_xxch_71_24_96_3840 \ > + xbr_51_24_48_3840 \ > + xbr_xch_61_24_48_3840 \ > + xbr_xxch_71_24_48_3840 \ > + xch_61_24_48_768 \ > + xxch_71_24_48_2046 \ > + > +define FATE_DCADEC_LOSSLESS_SUITE > +FATE_DCADEC_LOSSLESS += fate-dca-$(1) fate-dca-$(1)-dmix_2 > fate-dca-$(1)-dmix_6 > +fate-dca-$(1): CMD = framemd5 -i > $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -c:a pcm_$(2) > +fate-dca-$(1)-dmix_2: CMD = framemd5 -request_channel_layout 0x3 -i > $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -c:a pcm_$(2) > +fate-dca-$(1)-dmix_6: CMD = framemd5 -request_channel_layout 0x60f -i > $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -c:a pcm_$(2) > +endef > + > +define FATE_DCADEC_LOSSY_SUITE > +FATE_DCADEC_LOSSY += fate-dca-$(1) > +fate-dca-$(1): CMD = ffmpeg -i $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd > -f f32le - > +fate-dca-$(1): REF = $(SAMPLES)/dts/dcadec-suite/$(1).f32 > +endef > + > +$(foreach N,$(DCADEC_SUITE_LOSSLESS_16),$(eval $(call > FATE_DCADEC_LOSSLESS_SUITE,$(N),s16le))) > +$(foreach N,$(DCADEC_SUITE_LOSSLESS_24),$(eval $(call > FATE_DCADEC_LOSSLESS_SUITE,$(N),s24le))) > +$(foreach N,$(DCADEC_SUITE_LOSSY),$(eval $(call > FATE_DCADEC_LOSSY_SUITE,$(N > + > +# lossy downmix tests > +FATE_DCADEC_LOSSY += fate-dca-core_51_24_48_768_1-dmix_2 > +fate-dca-core_51_24_48_768_1-dmix_2: CMD = ffmpeg -request_channel_layout 3 > -i $(TARGET_SAMPLES)/dts/dcadec-suite/core_51_24_48_768_1.dtshd -f f32le - > +fate-dca-core_51_24_48_768_1-dmix_2: REF = > $(SAMPLES)/dts/dcadec-suite/core_51_24_48_768_1-dmix_2.f32 > + > +FATE_DCADEC_LOSSY += fate-dca-x96_xxch_71_24_96_3840-dmix_2 > +fate-dca-x96_xxch_71_24_96_3840-dmix_2: CMD = ffmpeg -request_channel_layout > 3 -i $(TARGET_SAMPLES)/dts/dcadec-suite/x96_xxch_71_24_96_3840.dtshd -f f32le > - > +# intentionally uses the dmix_6 reference because the sample does not > contain stereo downmix coefficients > +fate-dca-x96_xxch_71_24_96_3840-dmix_2: REF = > $(SAMPLES)/dts/dcadec-suite/x96_xxch_71_24_96_3840-dmix_6.f32 > + > +FATE_DCADEC_LOSSY += fate-dca-x96_xxch_71_24_96_3840-dmix_6 > +fate-dca-x96_xxch_71_24_96_3840-dmix_6: CMD = ffmpeg -request_channel_layout > 0x60f -i $(TARGET_SAMPLES)/dts/dcadec-suite/x96_xxch_71_24_96_3840.dtshd -f > f32le - > +fate-dca-x96_xxch_71_24_96_3840-dmix_6: REF = > $(SAMPLES)/dts/dcadec-suite/x96_xxch_71_24_96_3840-dmix_6.f32 > + > +FATE_DCADEC_LOSSY += fate-dca-xch_61_24_48_768-dmix_6 > +fate-dca-xch_61_24_48_768-dmix_6: CMD = ffmpeg -request_channel_layout 0x60f > -i $(TARGET_SAMPLES)/dts/dcadec-suite/xch_61_24_48_768.dtshd -f f32le - > +fate-dca-xch_61_24_48_768-dmix_6: REF = > $(SAMPLES)/dts/dcadec-suite/xch_61_24_48_768-dmix_6.f32 > + > +$(FATE_DCADEC_LOSSY): CMP = oneoff > +$(FATE_DCADEC_LOSSY): CMP_UNIT = f32 > +$(FATE_DCADEC_LOSSY): FUZZ = 9 I generated the ref files using cpuflags 0 on a mingw-w64 build, and FUZZ 7 was enough to make the tests succeed when using sse, avx or fma3. arm/aarch64 or some obscure arches we support will probably need more, so i guess 9 is a good start. Should be good, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/dirac: Add support for decoding interlaced HQ profile
From b919c9fa3d4778872bc9576705b24cd0c8193f4c Mon Sep 17 00:00:00 2001
From: Kieran Kunhya
Date: Tue, 2 Feb 2016 15:52:54 +
Subject: [PATCH] avcodec/dirac: Add support for decoding interlaced HQ profile
---
libavcodec/dirac.c| 15 ++-
libavcodec/dirac.h| 1 +
libavcodec/diracdec.c | 118 +-
3 files changed, 93 insertions(+), 41 deletions(-)
diff --git a/libavcodec/dirac.c b/libavcodec/dirac.c
index 39df2a8..d19adcf 100644
--- a/libavcodec/dirac.c
+++ b/libavcodec/dirac.c
@@ -324,7 +324,7 @@ int av_dirac_parse_sequence_header(AVDiracSeqHeader **pdsh,
{
AVDiracSeqHeader *dsh;
GetBitContext gb;
-unsigned video_format, picture_coding_mode;
+unsigned video_format;
int ret;
dsh = av_mallocz(sizeof(*dsh));
@@ -373,17 +373,8 @@ int av_dirac_parse_sequence_header(AVDiracSeqHeader **pdsh,
if (ret < 0)
goto fail;
-/* [DIRAC_STD] picture_coding_mode shall be 0 for fields and 1 for frames
- * currently only used to signal field coding */
-picture_coding_mode = svq3_get_ue_golomb(&gb);
-if (picture_coding_mode != 0) {
-if (log_ctx) {
-av_log(log_ctx, AV_LOG_ERROR, "Unsupported picture coding mode %d",
- picture_coding_mode);
-}
-ret = AVERROR_INVALIDDATA;
-goto fail;
-}
+/* [DIRAC_STD] picture_coding_mode shall be 1 for fields and 0
for frames */
+dsh->field_coding = svq3_get_ue_golomb(&gb);
*pdsh = dsh;
return 0;
diff --git a/libavcodec/dirac.h b/libavcodec/dirac.h
index cb80fdc..447fafc 100644
--- a/libavcodec/dirac.h
+++ b/libavcodec/dirac.h
@@ -74,6 +74,7 @@ typedef struct AVDiracSeqHeader {
uint8_t interlaced;
uint8_t top_field_first;
+uint8_t field_coding;
uint8_t frame_rate_index; ///< index into dirac_frame_rate[]
uint8_t aspect_ratio_index; ///< index into dirac_aspect_ratio[]
diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index ca44e7b..405cc5e 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -161,6 +161,8 @@ typedef struct DiracContext {
int dc_prediction; /* has dc prediction */
int globalmc_flag; /* use global motion compensation*/
int num_refs; /* number of reference pictures */
+int field_coding; /* fields instead of frames */
+int cur_field; /* 0 -> progressive/top, 1 -> bottom */
/* wavelet decoding */
unsigned wavelet_depth; /* depth of the IDWT */
@@ -227,6 +229,9 @@ typedef struct DiracContext {
dirac_weight_func weight_func;
dirac_biweight_func biweight_func;
+DiracFrame dummy_picture;
+
+DiracFrame prev_field;
DiracFrame *current_picture;
DiracFrame *ref_pics[2];
@@ -456,9 +461,11 @@ static av_cold int dirac_decode_init(AVCodecContext *avctx)
ff_mpegvideoencdsp_init(&s->mpvencdsp, avctx);
ff_videodsp_init(&s->vdsp, 8);
+s->dummy_picture.avframe = av_frame_alloc();
for (i = 0; i < MAX_FRAMES; i++) {
s->all_frames[i].avframe = av_frame_alloc();
if (!s->all_frames[i].avframe) {
+av_frame_free(&s->dummy_picture.avframe);
while (i > 0)
av_frame_free(&s->all_frames[--i].avframe);
return AVERROR(ENOMEM);
@@ -482,6 +489,7 @@ static av_cold int dirac_decode_end(AVCodecContext *avctx)
int i;
dirac_decode_flush(avctx);
+av_frame_free(&s->dummy_picture.avframe);
for (i = 0; i < MAX_FRAMES; i++)
av_frame_free(&s->all_frames[i].avframe);
@@ -1822,6 +1830,7 @@ static int dirac_decode_frame_internal(DiracContext *s)
for (comp = 0; comp < 3; comp++) {
Plane *p = &s->plane[comp];
uint8_t *frame = s->current_picture->avframe->data[comp];
+frame += s->cur_field*p->stride;
/* FIXME: small resolutions */
for (i = 0; i < 4; i++)
@@ -1838,11 +1847,12 @@ static int dirac_decode_frame_internal(DiracContext *s)
return ret;
if (!s->num_refs) { /* intra */
+const int idx = (s->bit_depth - 8) >> 1;
+const int ostride = p->stride << s->field_coding;
for (y = 0; y < p->height; y += 16) {
-int idx = (s->bit_depth - 8) >> 1;
ff_spatial_idwt_slice2(&d, y+16); /* decode */
-s->diracdsp.put_signed_rect_clamped[idx](frame + y*p->stride,
- p->stride,
+s->diracdsp.put_signed_rect_clamped[idx](frame + y*ostride,
+ ostride,
p->idwt_buf
+ y*p->idwt_stride,
p->idwt_stride, p->width, 16);
}
@@ -1929,10 +1939,10 @@ static int dirac_decode_picture_header(DiracContext
Re: [FFmpeg-devel] [FFmpeg-cvslog] build: use a link instead of changing current directory when compiling
On Mon, Jan 25, 2016 at 08:51:32PM +0100, Andreas Cadhalpun wrote: > ffmpeg | branch: master | Andreas Cadhalpun > | Mon Jan 25 01:42:23 2016 +0100| > [b46aae093634271931395d65f422f4b2a23112d3] | committer: Andreas Cadhalpun > > build: use a link instead of changing current directory when compiling > > If links don't work, fall back to using the full source path as was > previously done. > > This should fix build failures with MSVC. > This commit seems to break coverage. [~/ffbuild/lcov]☭ make lcov LCOVcoverage.info Cannot open source file src/ffmpeg_vdpau.c Cannot open source file src/tests/api/api-seek-test.c Cannot open source file src/tests/api/api-threadmessage-test.c Cannot open source file src/libavutil/mem.h Cannot open source file src/libavutil/error.h Cannot open source file src/tests/api/api-band-test.c Cannot open source file src/tests/api/api-h264-test.c Cannot open source file src/tests/api/api-flac-test.c Cannot open source file src/tests/api/api-codec-param-test.c Cannot open source file src/tests/checkasm/flacdsp.c Cannot open source file src/libavutil/x86/timer.h Cannot open source file src/libavutil/lfg.h Cannot open source file src/tests/checkasm/pixblockdsp.c Cannot open source file src/libavutil/x86/timer.h Cannot open source file src/libavutil/lfg.h Cannot open source file src/tests/checkasm/synth_filter.c Cannot open source file src/libavutil/lfg.h [...] How to reproduce: % ./configure --toolchain=gcov ... % make fate % make lcov [...] http://coverage.ffmpeg.org is broken because of this. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] diracdsp: Make x86 files/functions names consistent
On Tue, Feb 02, 2016 at 01:54:10AM -0300, James Almer wrote: > > diracdsp_init.o should be part of OBJS, not YASM-OBJS. There are some yasm function wrappers in that file that I'll need to wrap HAVE_YASM in, which is why I didn't push it into OBJS at first. > > While you're at it you could also change dirac_dwt in a similar > fashion. Okay. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] feature request: add instructions on the trac upload page for how to upload larger files
On 1/15/16, Michael Niedermayer wrote: > On Fri, Jan 15, 2016 at 02:00:19PM -0700, Roger Pack wrote: >> I know ways exist to "upload" a file larger than 2.5MB. >> However many people "at trac upload time" may be unfamiliar with those. >> Might be nice to add a link on the trac "upload" page to the >> instructions for larger files. Example page: >> https://trac.ffmpeg.org/attachment/ticket/3025/?action=new&attachfilebutton=Attach+file >> Just because its nice to have "instructions" right at the place where >> you run into needing them. >> Cheers! > > i dont know what needs to be edited to achive that but i can apply a > patch if someone posts one assuming thats how its supposed to be > changed I wonder if it would be possible to tweak some config setting so that 10 MB uploads is the max? 2.5 MB is sometimes a tricky target to reach with more chatty videos (at least for me anyway...) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] feature request: add instructions on the trac upload page for how to upload larger files
Roger Pack gmail.com> writes: > I wonder if it would be possible to tweak some config > setting so that 10 MB uploads is the max? Please don't! > 2.5 MB is sometimes a tricky target to > reach with more chatty videos (at least for me anyway...) Then just use incoming or another upload site. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Reworked patch
Here is my second attempt to push this patch. The changes since last time are: - The global code structure follows Nicolas George suggestions, with an if-else statement. - The silent truncate has been fixed: tag name length is not arbitrarily limited anymore. - The fate broken test has been updated ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] Add TargetTypeValue in Matroska tag prefix
Previously, the Matroska tag names were structured like this:
[/]
This lead to an issue when is not available: the different levels
tags overwrite each
other when they have the same name.
This patch transforms the name prefix into:
[-]/
As the TargetTypeValue has default value in case it has no data, it prevents
from overriding of other levels
tags.
---
libavformat/matroskadec.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d788232..d7d0e54 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1460,8 +1460,16 @@ static void matroska_convert_tags(AVFormatContext *s)
i, tags[i].target.trackuid);
}
} else {
-matroska_convert_tag(s, &tags[i].tag, &s->metadata,
- tags[i].target.type);
+char *prefix;
+if (tags[i].target.type)
+prefix = av_asprintf("%"PRIu64"-%s",
+ tags[i].target.typevalue,
+ tags[i].target.type);
+else
+prefix = av_asprintf("%"PRIu64, tags[i].target.typevalue);
+
+matroska_convert_tag(s, &tags[i].tag, &s->metadata, prefix);
+av_free(prefix);
}
}
}
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] Update fate ogg_vp3 expected result
Since the Matroska tag format has been modified, the target expected file checksum after conversion has been modified too. --- tests/ref/lavf-fate/ogg_vp3 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/ref/lavf-fate/ogg_vp3 b/tests/ref/lavf-fate/ogg_vp3 index 9e9cc7e..2e2626e 100644 --- a/tests/ref/lavf-fate/ogg_vp3 +++ b/tests/ref/lavf-fate/ogg_vp3 @@ -1,3 +1,3 @@ -4bd51dac3194fa88ae33767c25b4b1e6 *./tests/data/lavf-fate/lavf.ogg -417621 ./tests/data/lavf-fate/lavf.ogg +3704ef62ea932fbeeac84e709384643d *./tests/data/lavf-fate/lavf.ogg +417647 ./tests/data/lavf-fate/lavf.ogg ./tests/data/lavf-fate/lavf.ogg CRC=0x037e3e79 -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [SPI] Donation request to ffis.de
Hi, I propose to make a donation of 200 EUR to ffis.de to thank them for their services in the last two years. Currently the ffis.de FFmpeg fund contains 9195 EUR, so I would ask the ffis.de officers to directly grab from that fund. Note: due to the previous agreements, refund or expense requests must be sent to this list, and must be approved by the project maintainer and by the SPI FFmpeg liaison (me). Since we don't still have decided upon a formal organization, I'm assuming Michael Niedermayer is still the de-facto maintainer, so he can veto or approve this proposal. -- FFmpeg = Fancy and Fundamental Minimalistic Philosofic Evil Guru ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [SPI] Outreachy funding
Hi I Suggest that we fund 1 slot for outreachy (so that FFmpeg can participate in this round of Outreachy) assuming no sponsors are found The exact amount needed for this would be 6500 USD IIUC See: https://wiki.gnome.org/Outreachy/Admin/InfoForOrgs Thanks PS: if you know of or are some company who would want to sponsor this, please dont be shy and tell us -- 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
Re: [FFmpeg-devel] [PATCH 1/2] Add TargetTypeValue in Matroska tag prefix
Pierre Choffet wanadoo.fr> writes: > -matroska_convert_tag(s, &tags[i].tag, &s->metadata, The patch will get more readable if you don't change this line. And please add parenthesis around your else statement, they make the code easier to read. You have to merge the two patches: There should be no commit that breaks running fate. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/5] libavcodec: VAAPI support infrastructure
On 01/02/16 15:58, wm4 wrote:
> On Sat, 30 Jan 2016 22:11:52 +
> Mark Thompson wrote:
>
>> ---
>> configure | 5 +
>> libavcodec/Makefile| 1 +
>> libavcodec/vaapi_support.c | 710
>> +
>> libavcodec/vaapi_support.h | 122
>> 4 files changed, 838 insertions(+)
>> create mode 100644 libavcodec/vaapi_support.c
>> create mode 100644 libavcodec/vaapi_support.h
>>
>> diff --git a/configure b/configure
>> index dba8180..e7f53af 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2037,6 +2037,7 @@ CONFIG_EXTRA="
>> texturedsp
>> texturedspenc
>> tpeldsp
>> +vaapi_recent
>> videodsp
>> vp3dsp
>> vp56dsp
>> @@ -5768,6 +5769,10 @@ enabled vaapi &&
>> check_lib va/va.h vaInitialize -lva ||
>> disable vaapi
>>
>> +enabled vaapi &&
>> +check_code cc va/va.h "vaCreateSurfaces(0, 0, 0, 0, 0, 0, 0, 0)" &&
>> +enable vaapi_recent
>> +
>> enabled vaapi && enabled xlib &&
>> check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
>> enable vaapi_x11
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index de957d8..045d118 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -719,6 +719,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER) += adpcmenc.o
>> adpcm_data.o
>> OBJS-$(CONFIG_D3D11VA)+= dxva2.o
>> OBJS-$(CONFIG_DXVA2) += dxva2.o
>> OBJS-$(CONFIG_VAAPI) += vaapi.o
>> +OBJS-$(CONFIG_VAAPI_RECENT) += vaapi_support.o
>> OBJS-$(CONFIG_VDA)+= vda.o videotoolbox.o
>> OBJS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.o
>> OBJS-$(CONFIG_VDPAU) += vdpau.o
>> diff --git a/libavcodec/vaapi_support.c b/libavcodec/vaapi_support.c
>> new file mode 100644
>> index 000..2e22f98
>> --- /dev/null
>> +++ b/libavcodec/vaapi_support.c
>> @@ -0,0 +1,710 @@
>> +/*
>> + * VAAPI helper functions.
>> + *
>> + * Copyright (C) 2016 Mark Thompson
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
>> USA
>> + */
>> +
>> +#include "vaapi_support.h"
>> +
>> +#include "libavutil/avassert.h"
>> +#include "libavutil/imgutils.h"
>> +#include "libavutil/pixfmt.h"
>> +
>> +
>> +static AVClass vaapi_class = {
>> +.class_name = "vaapi",
>> +.item_name = av_default_item_name,
>> +.version= LIBAVUTIL_VERSION_INT,
>> +};
>> +static AVClass *vaapi_log = &vaapi_class;
>
> We've talked about it on IRC. So the idea was matching
> AVVAAPIHardwareContext with vaapi_context, which is why the first
> member of AVVAAPIHardwareContext can't be AVClass. I think trying to
> somehow make these structs compatible should be given up, and instead
> the struct should have a vaapi_context pointer field instead.
Yes.
> Also, I'm very worried about how this patch in general with combine
> with the API Libav is planning to add:
>
> https://lists.libav.org/pipermail/libav-devel/2016-January/074490.html
>
> To make this clear, above patch series:
> - extends the buffer pool to make it useful for the hwdec case (where
> you need to free the hw context when the final AVFrame is unreffed)
> - create a common API for hwaccel contexts, which overlaps with this
> patch to some degree, but not fully
> - adds a hwaccel context field to AVFrame
> - the hwaccel context is refcounted
> - adds helper for reading back data from hwaccel AVFrames in an
> API-independent way
>
> I'm not sure what to make out of this mess. Any ideas? I don't really
> want to hold this patch series back either. There is not much reason to
> refactor the whole API 1 week after it has been added either.
I'm not sure how to respond usefully to all of that, it adds a lot of new
things all over the place.
It looks like it has most of the elements needed here, though I would need to
examine it more carefully to be sure. (I don't see a way to do the "enumerate
all of a set of frames for something which requires all render targets in
advance" operation, but maybe I haven't looked hard enough.)
>> +
>> +
>> +AVVAAPIHardwareContext *av_vaapi_alloc_hardware_context(void)
>> +{
>> +return av_mallocz(sizeof(AVVAAPIHa
Re: [FFmpeg-devel] [PATCH] decklink: support all valid numbers of audio channels
On Sun, 20 Dec 2015, Matthias Hunstock wrote: As it is already written in the documentation, BMD DeckLink cards are capable of capturing 2, 8 or 16 audio channels (for SDI Inputs). Currently the value is hardcoded to 2. Introduces new option. Signed-off-by: Matthias Hunstock --- doc/indevs.texi | 13 - libavdevice/decklink_common_c.h | 1 + libavdevice/decklink_dec.cpp| 16 ++-- libavdevice/decklink_dec_c.c| 2 ++ 4 files changed, 29 insertions(+), 3 deletions(-) Deti, could you please ACK this patch as well? I will push it if its OK. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 2/5] ffmpeg: VAAPI hwaccel helper and related initialisation
On 01/02/16 16:08, wm4 wrote:
> On Sat, 30 Jan 2016 22:12:36 +
> Mark Thompson wrote:
>
>> ---
>> Makefile | 1 +
>> configure | 5 +
>> ffmpeg.c | 6 +
>> ffmpeg.h | 9 +
>> ffmpeg_opt.c | 38 +++-
>> ffmpeg_vaapi.c | 642
>> +
>> 6 files changed, 700 insertions(+), 1 deletion(-)
>> create mode 100644 ffmpeg_vaapi.c
>>
>> diff --git a/Makefile b/Makefile
>> index e484249..b2173bb 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -37,6 +37,7 @@ OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
>> endif
>> OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
>> OBJS-ffmpeg-$(CONFIG_LIBMFX) += ffmpeg_qsv.o
>> +OBJS-ffmpeg-$(CONFIG_VAAPI_RECENT) += ffmpeg_vaapi.o
>> OBJS-ffserver += ffserver_config.o
>>
>> TESTTOOLS = audiogen videogen rotozoom tiny_psnr tiny_ssim base64
>> diff --git a/configure b/configure
>> index e7f53af..d429cbb 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1965,6 +1965,7 @@ HAVE_LIST="
>> section_data_rel_ro
>> texi2html
>> threads
>> +vaapi_drm
>> vaapi_x11
>> vdpau_x11
>> winrt
>> @@ -5777,6 +5778,10 @@ enabled vaapi && enabled xlib &&
>> check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
>> enable vaapi_x11
>>
>> +enabled vaapi &&
>> +check_lib2 "va/va.h va/va_drm.h" vaGetDisplayDRM -lva -lva-drm &&
>> +enable vaapi_drm
>> +
>> enabled vdpau &&
>> check_cpp_condition vdpau/vdpau.h "defined
>> VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
>> disable vdpau
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index a5ec3c3..6616a07 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -2603,6 +2603,12 @@ static int init_output_stream(OutputStream *ost, char
>> *error, int error_len)
>> !av_dict_get(ost->encoder_opts, "ab", NULL, 0))
>> av_dict_set(&ost->encoder_opts, "b", "128000", 0);
>>
>> +#if CONFIG_VAAPI_RECENT
>> +if(ost->enc->type == AVMEDIA_TYPE_VIDEO &&
>> + strstr(ost->enc->name, "vaapi"))
>> +vaapi_hardware_set_options(&ost->encoder_opts);
>> +#endif
>> +
>> if ((ret = avcodec_open2(ost->enc_ctx, codec, &ost->encoder_opts))
>> < 0) {
>> if (ret == AVERROR_EXPERIMENTAL)
>> abort_codec_experimental(codec, 1);
>> diff --git a/ffmpeg.h b/ffmpeg.h
>> index 20322b0..85173a8 100644
>> --- a/ffmpeg.h
>> +++ b/ffmpeg.h
>> @@ -65,6 +65,7 @@ enum HWAccelID {
>> HWACCEL_VDA,
>> HWACCEL_VIDEOTOOLBOX,
>> HWACCEL_QSV,
>> +HWACCEL_VAAPI,
>> };
>>
>> typedef struct HWAccel {
>> @@ -126,6 +127,8 @@ typedef struct OptionsContext {
>> intnb_hwaccels;
>> SpecifierOpt *hwaccel_devices;
>> intnb_hwaccel_devices;
>> +SpecifierOpt *hwaccel_output_formats;
>> +intnb_hwaccel_output_formats;
>> SpecifierOpt *autorotate;
>> intnb_autorotate;
>>
>> @@ -325,6 +328,7 @@ typedef struct InputStream {
>> /* hwaccel options */
>> enum HWAccelID hwaccel_id;
>> char *hwaccel_device;
>> +enum AVPixelFormat hwaccel_output_format;
>>
>> /* hwaccel context */
>> enum HWAccelID active_hwaccel_id;
>> @@ -540,6 +544,7 @@ extern AVIOContext *progress_avio;
>> extern float max_error_rate;
>> extern int vdpau_api_ver;
>> extern char *videotoolbox_pixfmt;
>> +extern int hwaccel_lax_profile_check;
>>
>> extern const AVIOInterruptCB int_cb;
>>
>> @@ -577,5 +582,9 @@ int vda_init(AVCodecContext *s);
>> int videotoolbox_init(AVCodecContext *s);
>> int qsv_init(AVCodecContext *s);
>> int qsv_transcode_init(OutputStream *ost);
>> +int vaapi_decode_init(AVCodecContext *s);
>> +
>> +int vaapi_hardware_init(const char *device);
>> +int vaapi_hardware_set_options(AVDictionary **dict);
>>
>> #endif /* FFMPEG_H */
>> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
>> index 669976b..d65293e 100644
>> --- a/ffmpeg_opt.c
>> +++ b/ffmpeg_opt.c
>> @@ -82,8 +82,12 @@ const HWAccel hwaccels[] = {
>> #if CONFIG_LIBMFX
>> { "qsv", qsv_init, HWACCEL_QSV, AV_PIX_FMT_QSV },
>> #endif
>> +#if CONFIG_VAAPI_RECENT
>> +{ "vaapi", vaapi_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI },
>> +#endif
>> { 0 },
>> };
>> +int hwaccel_lax_profile_check = 0;
>>
>> char *vstats_filename;
>> char *sdp_filename;
>> @@ -442,6 +446,15 @@ static int opt_sdp_file(void *optctx, const char *opt,
>> const char *arg)
>> return 0;
>> }
>>
>> +#if CONFIG_VAAPI_RECENT
>> +static int opt_vaapi(void *optctx, const char *opt, const char *arg)
>> +{
>> +if(vaapi_hardware_init(arg))
>> +exit_program(1);
>> +return 0;
>> +}
>> +#endif
>> +
>> /**
>> * Parse a metadata specifier passed as 'arg' parameter.
>> * @param arg metadata string to parse
>> @@ -633,7 +646,8 @@ static void add_input_streams(OptionsContext *o,
>> AVFormatContext *ic)
>> AVStream *st = ic->streams[i];
>> AVCodecContext *dec = st->codec;
>>
Re: [FFmpeg-devel] [PATCH] decklink: support all valid numbers of audio channels
Hi Matthias, thanks for adding this necessary option. Please commit this patch. Deti On 02.02.16 20:58, Marton Balint wrote: On Sun, 20 Dec 2015, Matthias Hunstock wrote: As it is already written in the documentation, BMD DeckLink cards are capable of capturing 2, 8 or 16 audio channels (for SDI Inputs). Currently the value is hardcoded to 2. Introduces new option. Signed-off-by: Matthias Hunstock --- doc/indevs.texi | 13 - libavdevice/decklink_common_c.h | 1 + libavdevice/decklink_dec.cpp| 16 ++-- libavdevice/decklink_dec_c.c| 2 ++ 4 files changed, 29 insertions(+), 3 deletions(-) Deti, could you please ACK this patch as well? I will push it if its OK. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 5/5] libavfilter: VAAPI surface scaler
On 01/02/16 16:14, wm4 wrote:
> On Sat, 30 Jan 2016 22:15:04 +
> Mark Thompson wrote:
>> +{ "hardware_context", "VAAPI hardware context",
>> + OFFSET(hardware_context), AV_OPT_TYPE_INT64,
>> + { .i64 = 0 }, INT64_MIN, INT64_MAX, AV_OPT_FLAG_VIDEO_PARAM },
>
> Most of it is probably ok. But before it gets ready to be applied, I
> think we should find a semi-elegant way to populate the filter graph
> with the hw context. The "hardware_context" option is just a void*
> pointer, and there isn't anything that would prevent a big mess if e.g.
> vaapi support is introduced later.
>
> Seems like the Libav patch does provide something of value here with
> its generic hw context. It could be a field in AVFilterGraph itself.
Yeah, the libav patch does let you solve that problem by putting the
information generically in more places.
My rather inelegant thought was to add another function (and associated fields)
on the filter graph which applies options to all filters if the option is
present for them, something like:
int avfilter_graph_set_options_on_everything(AVFilterGraph *graph, AVDictionary
**options);
(Run before adding anything to the graph, because the options need to be
present at filter init time.) Unclear if it has any other use to justify its
existence, though. Also necessitates making the naming a bit more specific to
avoid possible collisions ("vaapi_hardware_context", I guess), and then being
careful with it in future.
The other way I can see to do it in ffmpeg is to know the set of filter names
and run through the whole graph to add the option to them, but there isn't
really a time which works to do it. In any case, it doesn't help lav* users.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [SPI] Outreachy funding
On Tue, 2 Feb 2016 19:35:09 +0100 Michael Niedermayer wrote: > Hi > > I Suggest that we fund 1 slot for outreachy (so that FFmpeg can if there is a mentor, i have no objections did we have any other plans for those funds? just curious. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC][WIP][PATCH] avfilter: add luascript filter
Hi,
patch attached.
From 5caafe2f74d6eb5563b1103193cc8d136edcfd0f Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 2 Feb 2016 10:09:50 +0100
Subject: [RFC][WIP][PATCH] avfilter: add luascript filter
Signed-off-by: Paul B Mahol
---
configure | 4 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/src_luascript.c | 428
4 files changed, 434 insertions(+)
create mode 100644 libavfilter/src_luascript.c
diff --git a/configure b/configure
index c415d5a..289c62e 100755
--- a/configure
+++ b/configure
@@ -275,6 +275,7 @@ External library support:
--disable-lzma disable lzma [autodetect]
--enable-decklinkenable Blackmagic DeckLink I/O support [no]
--enable-mmalenable decoding via MMAL [no]
+ --enable-lua51 enable lua5.1, needed for luascript filter [no]
--enable-netcdf enable NetCDF, needed for sofalizer filter [no]
--enable-nvenc enable NVIDIA NVENC support [no]
--enable-openal enable OpenAL 1.1 capture support [no]
@@ -1494,6 +1495,7 @@ EXTERNAL_LIBRARY_LIST="
libzimg
libzmq
libzvbi
+lua51
lzma
mmal
netcdf
@@ -2867,6 +2869,7 @@ hqdn3d_filter_deps="gpl"
interlace_filter_deps="gpl"
kerndeint_filter_deps="gpl"
ladspa_filter_deps="ladspa dlopen"
+luascript_filter_deps="lua51"
mcdeint_filter_deps="avcodec gpl"
movie_filter_deps="avcodec avformat"
mpdecimate_filter_deps="gpl"
@@ -5577,6 +5580,7 @@ enabled mmal &&
(check_code cc interface/mmal/mmal.h "MMAL_PARAMETER_VIDEO_MAX_NUM_CALLBACKS" ||
die "ERROR: mmal firmware headers too old")
+enabled lua51 && require_pkg_config lua5.1 lua.h lua_newstate
enabled netcdf&& require_pkg_config netcdf netcdf.h nc_inq_libvers
enabled nvenc && { check_header nvEncodeAPI.h || die "ERROR: nvEncodeAPI.h not found."; } &&
{ check_cpp_condition nvEncodeAPI.h "NVENCAPI_MAJOR_VERSION >= 5" ||
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e76d18e..bd9fce8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -298,6 +298,7 @@ OBJS-$(CONFIG_SPECTRUMSYNTH_FILTER) += vaf_spectrumsynth.o window_func.
# multimedia sources
OBJS-$(CONFIG_AMOVIE_FILTER) += src_movie.o
+OBJS-$(CONFIG_LUASCRIPT_FILTER) += src_luascript.o
OBJS-$(CONFIG_MOVIE_FILTER) += src_movie.o
# Windows resource file
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 27d54bc..00eb8a4 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -318,6 +318,7 @@ void avfilter_register_all(void)
/* multimedia sources */
REGISTER_FILTER(AMOVIE, amovie, avsrc);
+REGISTER_FILTER(LUASCRIPT, luascript, avsrc);
REGISTER_FILTER(MOVIE, movie, avsrc);
/* those filters are part of public or internal API => registered
diff --git a/libavfilter/src_luascript.c b/libavfilter/src_luascript.c
new file mode 100644
index 000..949256e
--- /dev/null
+++ b/libavfilter/src_luascript.c
@@ -0,0 +1,428 @@
+/*
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include "libavutil/attributes.h"
+#include "libavutil/avstring.h"
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/internal.h"
+#include "libavutil/timestamp.h"
+#include "libavformat/avformat.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "buffersink.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct FiltersContext {
+AVFilterContext *f;
+char *options;
+char *in;
+char *out;
+} FiltersContext;
+
+typedef struct LuaScriptContext {
+const AVClass *class;
+char *script;
+int width;
+int height;
+
+AVFilterGraph *graph;
+FiltersContext fctx[1024];
+AVFilterContext *sink[32];
+int nbf;
+
+lua_State *L;
+} LuaScriptContext;
+
+#define OFFSET(x) offsetof(LuaScriptContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FL
[FFmpeg-devel] Fwd: Questionable libav code
libavcodec has codes like this one (utils.c):
static AVPacket *add_to_pktbuf(AVPacketList **packet_buffer, AVPacket *pkt,
AVPacketList **plast_pktl)
{
AVPacketList *pktl = av_mallocz(sizeof(AVPacketList));
if (!pktl)
return NULL;
if (*packet_buffer)
(*plast_pktl)->next = pktl;
else
*packet_buffer = pktl;
/* Add the packet in the buffered packet list. */
*plast_pktl = pktl;
pktl->pkt = *pkt; <===
return &pktl->pkt;
}
Here a struct variable is meant to be copied over via assignment, is that
100% correct to always work the way was intended? Given that the struct
pkt is a big struct which has raw bytes that are malloc'd. I was always
trained to avoid such struct assignment operations. What do people think?
Ratin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] build: use a link instead of changing current directory when compiling
On 02.02.2016 17:13, Clément Bœsch wrote: > On Mon, Jan 25, 2016 at 08:51:32PM +0100, Andreas Cadhalpun wrote: >> ffmpeg | branch: master | Andreas Cadhalpun >> | Mon Jan 25 01:42:23 2016 +0100| >> [b46aae093634271931395d65f422f4b2a23112d3] | committer: Andreas Cadhalpun >> >> build: use a link instead of changing current directory when compiling >> >> If links don't work, fall back to using the full source path as was >> previously done. >> >> This should fix build failures with MSVC. >> > > This commit seems to break coverage. > > [~/ffbuild/lcov]☭ make lcov > LCOV coverage.info > Cannot open source file src/ffmpeg_vdpau.c > [...] I see, it passes '-b $(SRC_PATH)' to lcov, which is now unnecessary/harmful for out-of-tree builds using the src link. The first attached patch changes it to simply use the current directory in that case. The second patch was necessary to fix the following error: lcov: ERROR: cannot write to coverage.info! Does it work for you without that patch? > http://coverage.ffmpeg.org is broken because of this. It would be great if that site would have a more meaningful error message than '404 Not Found'. Best regards, Andreas >From ac789e76bd28ac067591b58165094788a376fd6c Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun Date: Wed, 3 Feb 2016 00:24:21 +0100 Subject: [PATCH 1/2] build: fix lcov with src link When out-of-tree builds now use a relative path, the '-b' option of lcov is not needed, so just pass the current directory to it in this case. Signed-off-by: Andreas Cadhalpun --- tests/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile b/tests/Makefile index ac524ac..db2bc61 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -216,7 +216,7 @@ fate-list: coverage.info: TAG = LCOV coverage.info: - $(M)lcov -q -d $(CURDIR) -b $(SRC_PATH) --capture | \ + $(M)lcov -q -d $(CURDIR) -b $(patsubst src%,./,$(SRC_LINK)) --capture | \ sed "s,$(CURDIR)/\./,$(CURDIR)/," > $@ $(M)lcov -q --remove $@ "/usr*" -o $@ -- 2.7.0 >From a61f724079be9b0193ab7f917f13f1b4e5c10eeb Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun Date: Wed, 3 Feb 2016 00:24:26 +0100 Subject: [PATCH 2/2] build: use intermediate lcov coverage file Otherwise the 'lcov -q --remove' run fails with the following error: lcov: ERROR: cannot write to coverage.info! Signed-off-by: Andreas Cadhalpun --- tests/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index db2bc61..6e5dfa6 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -217,8 +217,9 @@ fate-list: coverage.info: TAG = LCOV coverage.info: $(M)lcov -q -d $(CURDIR) -b $(patsubst src%,./,$(SRC_LINK)) --capture | \ - sed "s,$(CURDIR)/\./,$(CURDIR)/," > $@ - $(M)lcov -q --remove $@ "/usr*" -o $@ + sed "s,$(CURDIR)/\./,$(CURDIR)/," > $@.in + $(M)lcov -q --remove $@.in "/usr*" > $@ + $(Q)$(RM) $@.in lcov: TAG = GENHTML lcov: coverage.info -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rtpdec: support for VC-2 HQ RTP payload format (draft v1)
On Tue, Feb 02, 2016 at 12:21:53AM +0100, Thomas Volkert wrote: > This implements the receiver side for > https://tools.ietf.org/html/draft-weaver-payload-rtp-vc2hq-01 > > --- > Changelog| 1 + > libavformat/Makefile | 1 + > libavformat/rtpdec.c | 1 + > libavformat/rtpdec_formats.h | 1 + > libavformat/rtpdec_vc2hq.c | 227 > +++ > libavformat/version.h| 4 +- > 6 files changed, 233 insertions(+), 2 deletions(-) > create mode 100644 libavformat/rtpdec_vc2hq.c > > diff --git a/Changelog b/Changelog > index 2f2ca3e..0b484d8 100644 > --- a/Changelog > +++ b/Changelog > @@ -64,6 +64,7 @@ version : > - new DCA decoder with full support for DTS-HD extensions > - significant performance improvements in Windows Television (WTV) demuxer > - nnedi deinterlacer > +- VC-2 HQ RTP payload format (draft v1) depacketizer > > > version 2.8: > diff --git a/libavformat/Makefile b/libavformat/Makefile > index 35a383d..db86742 100644 > --- a/libavformat/Makefile > +++ b/libavformat/Makefile > @@ -51,6 +51,7 @@ OBJS-$(CONFIG_RTPDEC)+= rdt.o > \ > rtpdec_qdm2.o \ > rtpdec_qt.o \ > rtpdec_svq3.o \ > + rtpdec_vc2hq.o \ doesnt apply Applying: rtpdec: support for VC-2 HQ RTP payload format (draft v1) fatal: corrupt patch at line 29 Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 rtpdec: support for VC-2 HQ RTP payload format (draft v1) When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cfhd: fix off-by-one error in level check
This fixes out-of-bounds writes causing segmentation faults.
Found-by: Piotr Bandurski
Signed-off-by: Andreas Cadhalpun
---
Didn't you want to fix this before pushing?
---
libavcodec/cfhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 410bb7b..2436aae 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -280,7 +280,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
s->level++;
av_log(avctx, AV_LOG_DEBUG, "Subband number %"PRIu16"\n", data);
s->subband_num = data;
-if (s->level > DWT_LEVELS) {
+if (s->level >= DWT_LEVELS) {
av_log(avctx, AV_LOG_ERROR, "Invalid level\n");
ret = AVERROR(EINVAL);
break;
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] decklink: support all valid numbers of audio channels
On Tue, 2 Feb 2016, Deti Fliegl wrote: Hi Matthias, thanks for adding this necessary option. Please commit this patch. Deti On 02.02.16 20:58, Marton Balint wrote: On Sun, 20 Dec 2015, Matthias Hunstock wrote: As it is already written in the documentation, BMD DeckLink cards are capable of capturing 2, 8 or 16 audio channels (for SDI Inputs). Currently the value is hardcoded to 2. Introduces new option. Thank you all, pushed. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cfhd: fix off-by-one error in level check
On 03.02.2016 01:16, Kieran Kunhya wrote: > On Tue, Feb 2, 2016 at 11:59 PM, Andreas Cadhalpun > wrote: >> This fixes out-of-bounds writes causing segmentation faults. >> >> Found-by: Piotr Bandurski >> Signed-off-by: Andreas Cadhalpun >> --- >> >> Didn't you want to fix this before pushing? > > Not really sure how this didn't make it into the push to be honest. > Please push ASAP. Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf: forward protocol_whitelist for the remaining cases
Also set a default_whitelist for mmsh and ffrtmphttp.
Signed-off-by: Andreas Cadhalpun
---
libavformat/mmsh.c | 9 +
libavformat/rtmphttp.c | 9 +
libavformat/rtsp.c | 8
3 files changed, 26 insertions(+)
diff --git a/libavformat/mmsh.c b/libavformat/mmsh.c
index 16f07fe..d992337 100644
--- a/libavformat/mmsh.c
+++ b/libavformat/mmsh.c
@@ -246,6 +246,14 @@ static int mmsh_open_internal(URLContext *h, const char
*uri, int flags, int tim
host, port, mmsh->request_seq++);
av_opt_set(mms->mms_hd->priv_data, "headers", headers, 0);
+if (!mms->mms_hd->protocol_whitelist && h->protocol_whitelist) {
+mms->mms_hd->protocol_whitelist = av_strdup(h->protocol_whitelist);
+if (!mms->mms_hd->protocol_whitelist) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+}
+
err = ffurl_connect(mms->mms_hd, NULL);
if (err) {
goto fail;
@@ -410,4 +418,5 @@ URLProtocol ff_mmsh_protocol = {
.url_read_seek = mmsh_read_seek,
.priv_data_size = sizeof(MMSHContext),
.flags = URL_PROTOCOL_FLAG_NETWORK,
+.default_whitelist = "http,tcp",
};
diff --git a/libavformat/rtmphttp.c b/libavformat/rtmphttp.c
index 8ed5eb1..c8a15e3 100644
--- a/libavformat/rtmphttp.c
+++ b/libavformat/rtmphttp.c
@@ -220,6 +220,14 @@ static int rtmp_http_open(URLContext *h, const char *uri,
int flags)
av_opt_set(rt->stream->priv_data, "multiple_requests", "1", 0);
av_opt_set_bin(rt->stream->priv_data, "post_data", "", 1, 0);
+if (!rt->stream->protocol_whitelist && h->protocol_whitelist) {
+rt->stream->protocol_whitelist = av_strdup(h->protocol_whitelist);
+if (!rt->stream->protocol_whitelist) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+}
+
/* open the http context */
if ((ret = ffurl_connect(rt->stream, NULL)) < 0)
goto fail;
@@ -274,4 +282,5 @@ URLProtocol ff_ffrtmphttp_protocol = {
.priv_data_size = sizeof(RTMP_HTTPContext),
.flags = URL_PROTOCOL_FLAG_NETWORK,
.priv_data_class= &ffrtmphttp_class,
+.default_whitelist = "https,http,tcp",
};
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index d710469..24a1e2b 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1746,6 +1746,14 @@ redirect:
sessioncookie);
av_opt_set(rt->rtsp_hd->priv_data, "headers", headers, 0);
+if (!rt->rtsp_hd->protocol_whitelist && s->protocol_whitelist) {
+rt->rtsp_hd->protocol_whitelist = av_strdup(s->protocol_whitelist);
+if (!rt->rtsp_hd->protocol_whitelist) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+}
+
/* complete the connection */
if (ffurl_connect(rt->rtsp_hd, NULL)) {
err = AVERROR(EIO);
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] Update demuxers and protocols for protocol whitelist support
On 02.02.2016 04:16, Michael Niedermayer wrote: > On Tue, Feb 02, 2016 at 12:45:32AM +0100, Andreas Cadhalpun wrote: >> I don't see how hls is fixed, but don't have testcases either. >> Anyway, the following should work: > > the hls segfaulted > i somehow must have lost the hunk that fixed it > > pushed with the fix Thanks for fixing that. > i left the rtp stuff as its your code and shuld be commited under > your name as author OK, I sent a patch for that. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avformat: add vc2 as an allowed rawenc Dirac extension
On Tue, Feb 02, 2016 at 12:35:30PM +, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov > --- > libavformat/rawenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dirac: Add support for decoding interlaced HQ profile
On Tue, Feb 02, 2016 at 03:55:11PM +, Kieran Kunhya wrote:
> From b919c9fa3d4778872bc9576705b24cd0c8193f4c Mon Sep 17 00:00:00 2001
> From: Kieran Kunhya
> Date: Tue, 2 Feb 2016 15:52:54 +
> Subject: [PATCH] avcodec/dirac: Add support for decoding interlaced HQ profile
>
> ---
> libavcodec/dirac.c| 15 ++-
> libavcodec/dirac.h| 1 +
> libavcodec/diracdec.c | 118
> +-
> 3 files changed, 93 insertions(+), 41 deletions(-)
>
> diff --git a/libavcodec/dirac.c b/libavcodec/dirac.c
> index 39df2a8..d19adcf 100644
> --- a/libavcodec/dirac.c
> +++ b/libavcodec/dirac.c
> @@ -324,7 +324,7 @@ int av_dirac_parse_sequence_header(AVDiracSeqHeader
> **pdsh,
> {
> AVDiracSeqHeader *dsh;
> GetBitContext gb;
> -unsigned video_format, picture_coding_mode;
> +unsigned video_format;
> int ret;
>
> dsh = av_mallocz(sizeof(*dsh));
> @@ -373,17 +373,8 @@ int av_dirac_parse_sequence_header(AVDiracSeqHeader
> **pdsh,
> if (ret < 0)
> goto fail;
>
> -/* [DIRAC_STD] picture_coding_mode shall be 0 for fields and 1 for frames
> - * currently only used to signal field coding */
> -picture_coding_mode = svq3_get_ue_golomb(&gb);
> -if (picture_coding_mode != 0) {
> -if (log_ctx) {
> -av_log(log_ctx, AV_LOG_ERROR, "Unsupported picture coding mode
> %d",
> - picture_coding_mode);
> -}
> -ret = AVERROR_INVALIDDATA;
> -goto fail;
> -}
> +/* [DIRAC_STD] picture_coding_mode shall be 1 for fields and 0
> for frames */
> +dsh->field_coding = svq3_get_ue_golomb(&gb);
this seems not to apply cleanly
Applying: avcodec/dirac: Add support for decoding interlaced HQ profile
fatal: corrupt patch at line 36
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
also tools/unwrap-diff fails
patching file libavcodec/dirac.c
Hunk #2 succeeded at 373 with fuzz 1.
patching file libavcodec/dirac.h
Hunk #1 succeeded at 85 with fuzz 1 (offset 11 lines).
patching file libavcodec/diracdec.c
Hunk #1 succeeded at 151 (offset -10 lines).
Hunk #2 succeeded at 219 (offset -10 lines).
Hunk #3 succeeded at 384 (offset -77 lines).
Hunk #4 succeeded at 412 (offset -77 lines).
Hunk #5 succeeded at 1753 (offset -77 lines).
patch: malformed patch at line 113: }
[...]
--
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
Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter
On 1/30/2016 2:26 PM, Paul B Mahol wrote: > Should be fixed in 4th version attached. CC libavfilter/vf_nnedi.o src/libavfilter/vf_nnedi.c: In function ‘extract_m8’: src/libavfilter/vf_nnedi.c:506:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] const float scale = 1.0f / (xdia * ydia); ^ src/libavfilter/vf_nnedi.c:508:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] const double tmp = (double)sumsq * scale - (double)mstd[0] * mstd[0]; ^ src/libavfilter/vf_nnedi.c: In function ‘extract_m8_i16’: src/libavfilter/vf_nnedi.c:533:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] const float scale = 1.0f / (float)(xdia * ydia); ^ src/libavfilter/vf_nnedi.c: In function ‘evalfunc_1’: src/libavfilter/vf_nnedi.c:593:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] const uint8_t *srcp = (const uint8_t *)frame_data->paddedp[plane]; ^ src/libavfilter/vf_nnedi.c:607:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] const uint8_t *srcpp = srcp - (ydia - 1) * src_stride - xdiad2m1; ^ src/libavfilter/vf_nnedi.c:614:17: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] uint32_t all_ones = 0; ^~~~ src/libavfilter/vf_nnedi.c:620:17: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] float mstd[4]; ^ src/libavfilter/vf_nnedi.c: In function ‘init’: src/libavfilter/vf_nnedi.c:1054:17: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] const double scale = 32767.0 / mval; ^ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libvpxenc: Allow setting tune parameter
---
doc/encoders.texi | 6 ++
libavcodec/libvpxenc.c | 8
2 files changed, 14 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index c485f90..e9311eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1584,6 +1584,12 @@ follows: @code{(minrate * 100 / bitrate)}.
@item crf (@emph{end-usage=cq}, @emph{cq-level})
+@item tune (@emph{tune})
+@table @samp
+@item psnr (@emph{psnr})
+@item ssim (@emph{ssim})
+@end table
+
@item quality, deadline (@emph{deadline})
@table @samp
@item best
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 643855a..8992497 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -88,6 +88,8 @@ typedef struct VP8EncoderContext {
int arnr_strength;
int arnr_type;
+int tune;
+
int lag_in_frames;
int error_resilient;
int crf;
@@ -116,6 +118,7 @@ static const char *const ctlidstr[] = {
[VP8E_SET_ARNR_MAXFRAMES]= "VP8E_SET_ARNR_MAXFRAMES",
[VP8E_SET_ARNR_STRENGTH] = "VP8E_SET_ARNR_STRENGTH",
[VP8E_SET_ARNR_TYPE] = "VP8E_SET_ARNR_TYPE",
+[VP8E_SET_TUNING]= "VP8E_SET_TUNING",
[VP8E_SET_CQ_LEVEL] = "VP8E_SET_CQ_LEVEL",
[VP8E_SET_MAX_INTRA_BITRATE_PCT] = "VP8E_SET_MAX_INTRA_BITRATE_PCT",
#if CONFIG_LIBVPX_VP9_ENCODER
@@ -611,6 +614,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
codecctl_int(avctx, VP8E_SET_ARNR_STRENGTH,ctx->arnr_strength);
if (ctx->arnr_type >= 0)
codecctl_int(avctx, VP8E_SET_ARNR_TYPE,ctx->arnr_type);
+if (ctx->tune >= 0)
+codecctl_int(avctx, VP8E_SET_TUNING, ctx->tune);
if (CONFIG_LIBVPX_VP8_ENCODER && avctx->codec_id == AV_CODEC_ID_VP8) {
#if FF_API_PRIVATE_OPT
@@ -1010,6 +1015,9 @@ static int vp8_encode(AVCodecContext *avctx, AVPacket
*pkt,
{ "backward",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 0, VE,
"arnr_type" }, \
{ "forward", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 2}, 0, 0, VE,
"arnr_type" }, \
{ "centered",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 3}, 0, 0, VE,
"arnr_type" }, \
+{ "tune","Tune the encoding to a specific scenario",
OFFSET(tune), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VE,
"tune"}, \
+{ "psnr",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VP8_TUNE_PSNR},
0, 0, VE, "tune"}, \
+{ "ssim",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VP8_TUNE_SSIM},
0, 0, VE, "tune"}, \
{ "deadline","Time to spend encoding, in microseconds.",
OFFSET(deadline), AV_OPT_TYPE_INT, {.i64 = VPX_DL_GOOD_QUALITY}, INT_MIN,
INT_MAX, VE, "quality"}, \
{ "best",NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
VPX_DL_BEST_QUALITY}, 0, 0, VE, "quality"}, \
{ "good",NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
VPX_DL_GOOD_QUALITY}, 0, 0, VE, "quality"}, \
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] sdl: Remove AVPicture usage
On Mon, Feb 01, 2016 at 07:04:06PM -0800, Timothy Gu wrote: > --- > libavdevice/sdl.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) Set pushed. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpxenc: Allow setting tune parameter
On Tue, Feb 2, 2016 at 6:10 PM, Timothy Gu wrote:
> ---
> doc/encoders.texi | 6 ++
> libavcodec/libvpxenc.c | 8
> 2 files changed, 14 insertions(+)
>
lgtm
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index c485f90..e9311eb 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1584,6 +1584,12 @@ follows: @code{(minrate * 100 / bitrate)}.
>
> @item crf (@emph{end-usage=cq}, @emph{cq-level})
>
> +@item tune (@emph{tune})
> +@table @samp
> +@item psnr (@emph{psnr})
> +@item ssim (@emph{ssim})
> +@end table
> +
>
For other parameters that match I think the vpxenc equivalent is left
out currently, your choice.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] diracdsp: Make x86 files/functions names consistent
On Tue, Feb 02, 2016 at 01:54:10AM -0300, James Almer wrote:
> > diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> > index ce06b90..301b39b 100644
> > --- a/libavcodec/x86/Makefile
> > +++ b/libavcodec/x86/Makefile
> > @@ -133,7 +133,7 @@ YASM-OBJS-$(CONFIG_ADPCM_G722_ENCODER) += x86/g722dsp.o
> > YASM-OBJS-$(CONFIG_ALAC_DECODER) += x86/alacdsp.o
> > YASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
> > YASM-OBJS-$(CONFIG_DCA_DECODER)+= x86/synth_filter.o
> > -YASM-OBJS-$(CONFIG_DIRAC_DECODER) += x86/diracdsp_mmx.o
> > x86/diracdsp_yasm.o \
> > +YASM-OBJS-$(CONFIG_DIRAC_DECODER) += x86/diracdsp.o
> > x86/diracdsp_init.o \
>
> diracdsp_init.o should be part of OBJS, not YASM-OBJS.
Done.
>
> While you're at it you could also change dirac_dwt in a similar
> fashion.
And done.
Timothy
>From af049dcfa5d769b5a48fc0768790a3a406d4035e Mon Sep 17 00:00:00 2001
From: Timothy Gu
Date: Mon, 1 Feb 2016 20:50:22 -0800
Subject: [PATCH 1/2] diracdsp: Make x86 files/functions names consistent
---
libavcodec/diracdsp.c | 4 +-
libavcodec/diracdsp.h | 1 +
libavcodec/x86/Makefile| 3 +-
libavcodec/x86/{diracdsp_yasm.asm => diracdsp.asm} | 0
libavcodec/x86/{diracdsp_mmx.c => diracdsp_init.c} | 45 +
libavcodec/x86/diracdsp_mmx.h | 47 --
6 files changed, 43 insertions(+), 57 deletions(-)
rename libavcodec/x86/{diracdsp_yasm.asm => diracdsp.asm} (100%)
rename libavcodec/x86/{diracdsp_mmx.c => diracdsp_init.c} (80%)
delete mode 100644 libavcodec/x86/diracdsp_mmx.h
diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
index 12f27ce..ab8d149 100644
--- a/libavcodec/diracdsp.c
+++ b/libavcodec/diracdsp.c
@@ -20,7 +20,6 @@
#include "avcodec.h"
#include "diracdsp.h"
-#include "libavcodec/x86/diracdsp_mmx.h"
#define FILTER(src, stride) \
((21*((src)[ 0*stride] + (src)[1*stride]) \
@@ -222,5 +221,6 @@ av_cold void ff_diracdsp_init(DiracDSPContext *c)
PIXFUNC(avg, 16);
PIXFUNC(avg, 32);
-if (HAVE_MMX && HAVE_YASM) ff_diracdsp_init_mmx(c);
+if (ARCH_X86)
+ff_diracdsp_init_x86(c);
}
diff --git a/libavcodec/diracdsp.h b/libavcodec/diracdsp.h
index 439bda2..25a872d 100644
--- a/libavcodec/diracdsp.h
+++ b/libavcodec/diracdsp.h
@@ -63,5 +63,6 @@ DECL_DIRAC_PIXOP(put, l4_c);
DECL_DIRAC_PIXOP(avg, l4_c);
void ff_diracdsp_init(DiracDSPContext *c);
+void ff_diracdsp_init_x86(DiracDSPContext* c);
#endif /* AVCODEC_DIRACDSP_H */
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index ce06b90..1baec49 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -6,6 +6,7 @@ OBJS-$(CONFIG_AUDIODSP)+= x86/audiodsp_init.o
OBJS-$(CONFIG_BLOCKDSP)+= x86/blockdsp_init.o
OBJS-$(CONFIG_BSWAPDSP)+= x86/bswapdsp_init.o
OBJS-$(CONFIG_DCT) += x86/dct_init.o
+OBJS-$(CONFIG_DIRAC_DECODER) += x86/diracdsp_init.o
OBJS-$(CONFIG_FDCTDSP) += x86/fdctdsp_init.o
OBJS-$(CONFIG_FFT) += x86/fft_init.o
OBJS-$(CONFIG_FLACDSP) += x86/flacdsp_init.o
@@ -133,7 +134,7 @@ YASM-OBJS-$(CONFIG_ADPCM_G722_ENCODER) += x86/g722dsp.o
YASM-OBJS-$(CONFIG_ALAC_DECODER) += x86/alacdsp.o
YASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
YASM-OBJS-$(CONFIG_DCA_DECODER)+= x86/synth_filter.o
-YASM-OBJS-$(CONFIG_DIRAC_DECODER) += x86/diracdsp_mmx.o x86/diracdsp_yasm.o \
+YASM-OBJS-$(CONFIG_DIRAC_DECODER) += x86/diracdsp.o\
x86/dwt_yasm.o
YASM-OBJS-$(CONFIG_DNXHD_ENCODER) += x86/dnxhdenc.o
YASM-OBJS-$(CONFIG_FLAC_DECODER) += x86/flacdsp.o
diff --git a/libavcodec/x86/diracdsp_yasm.asm b/libavcodec/x86/diracdsp.asm
similarity index 100%
rename from libavcodec/x86/diracdsp_yasm.asm
rename to libavcodec/x86/diracdsp.asm
diff --git a/libavcodec/x86/diracdsp_mmx.c b/libavcodec/x86/diracdsp_init.c
similarity index 80%
rename from libavcodec/x86/diracdsp_mmx.c
rename to libavcodec/x86/diracdsp_init.c
index d260364..5fae798 100644
--- a/libavcodec/x86/diracdsp_mmx.c
+++ b/libavcodec/x86/diracdsp_init.c
@@ -19,14 +19,35 @@
*/
#include "libavutil/x86/cpu.h"
-#include "diracdsp_mmx.h"
+#include "libavcodec/diracdsp.h"
#include "fpel.h"
+DECL_DIRAC_PIXOP(put, mmx);
+DECL_DIRAC_PIXOP(avg, mmx);
+DECL_DIRAC_PIXOP(avg, mmxext);
+
+void ff_put_dirac_pixels16_sse2(uint8_t *dst, const uint8_t *src[5], int stride, int h);
+void ff_avg_dirac_pixels16_sse2(uint8_t *dst, const uint8_t *src[5], int stride, int h);
+void ff_put_dirac_pixels32_sse2(uint8_t *dst, const uint8_t *src[5], int stride, int h);
+void ff_avg_dirac_pixels32_sse2(uint8_t *dst, const uint8_t *src[5], int stride, int h);
+
+void ff_add_rect_clamped_mmx(uint8_t *, const
Re: [FFmpeg-devel] [SPI] Outreachy funding
On Tue, Feb 02, 2016 at 03:47:11PM -0500, compn wrote: > On Tue, 2 Feb 2016 19:35:09 +0100 > Michael Niedermayer wrote: > > > Hi > > > > I Suggest that we fund 1 slot for outreachy (so that FFmpeg can > > if there is a mentor, i have no objections > > did we have any other plans for those funds? just curious. watching it fade away as the government prints money and devalues it that way [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: forward protocol_whitelist for the remaining cases
On Wed, Feb 03, 2016 at 01:51:55AM +0100, Andreas Cadhalpun wrote:
> Also set a default_whitelist for mmsh and ffrtmphttp.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/mmsh.c | 9 +
> libavformat/rtmphttp.c | 9 +
> libavformat/rtsp.c | 8
> 3 files changed, 26 insertions(+)
>
> diff --git a/libavformat/mmsh.c b/libavformat/mmsh.c
> index 16f07fe..d992337 100644
> --- a/libavformat/mmsh.c
> +++ b/libavformat/mmsh.c
> @@ -246,6 +246,14 @@ static int mmsh_open_internal(URLContext *h, const char
> *uri, int flags, int tim
> host, port, mmsh->request_seq++);
> av_opt_set(mms->mms_hd->priv_data, "headers", headers, 0);
>
> +if (!mms->mms_hd->protocol_whitelist && h->protocol_whitelist) {
> +mms->mms_hd->protocol_whitelist = av_strdup(h->protocol_whitelist);
> +if (!mms->mms_hd->protocol_whitelist) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +}
> +
> err = ffurl_connect(mms->mms_hd, NULL);
> if (err) {
> goto fail;
> @@ -410,4 +418,5 @@ URLProtocol ff_mmsh_protocol = {
> .url_read_seek = mmsh_read_seek,
> .priv_data_size = sizeof(MMSHContext),
> .flags = URL_PROTOCOL_FLAG_NETWORK,
> +.default_whitelist = "http,tcp",
> };
> diff --git a/libavformat/rtmphttp.c b/libavformat/rtmphttp.c
> index 8ed5eb1..c8a15e3 100644
> --- a/libavformat/rtmphttp.c
> +++ b/libavformat/rtmphttp.c
> @@ -220,6 +220,14 @@ static int rtmp_http_open(URLContext *h, const char
> *uri, int flags)
> av_opt_set(rt->stream->priv_data, "multiple_requests", "1", 0);
> av_opt_set_bin(rt->stream->priv_data, "post_data", "", 1, 0);
>
> +if (!rt->stream->protocol_whitelist && h->protocol_whitelist) {
> +rt->stream->protocol_whitelist = av_strdup(h->protocol_whitelist);
> +if (!rt->stream->protocol_whitelist) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +}
> +
> /* open the http context */
> if ((ret = ffurl_connect(rt->stream, NULL)) < 0)
> goto fail;
> @@ -274,4 +282,5 @@ URLProtocol ff_ffrtmphttp_protocol = {
> .priv_data_size = sizeof(RTMP_HTTPContext),
> .flags = URL_PROTOCOL_FLAG_NETWORK,
> .priv_data_class= &ffrtmphttp_class,
> +.default_whitelist = "https,http,tcp",
if it needs https it might need tls too
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] sdl: Remove AVPicture usage
On 2/2/2016 11:17 PM, Timothy Gu wrote: > On Mon, Feb 01, 2016 at 07:04:06PM -0800, Timothy Gu wrote: >> --- >> libavdevice/sdl.c | 10 ++ >> 1 file changed, 6 insertions(+), 4 deletions(-) > > Set pushed. > > Timothy You sent this set last night. There was no reason to push it in a hurry without waiting for a review. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/emms: run the instruction unconditionally on supported targets
Inlined functions like AV_ZERO* and AV_COPY* may use mmx instructions
regardless of runtime cpuflags.
Signed-off-by: James Almer
---
On targets where __MMX__ is not defined (like default x86_32 builds) the
runtime check is a must, and neither of the above functions will use mmx
instructions anyway.
libavutil/x86/emms.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/x86/emms.h b/libavutil/x86/emms.h
index a529b6b..0deeb8c 100644
--- a/libavutil/x86/emms.h
+++ b/libavutil/x86/emms.h
@@ -34,7 +34,9 @@ void avpriv_emms_yasm(void);
*/
static av_always_inline void emms_c(void)
{
+#if !defined(__MMX__)
if(av_get_cpu_flags() & AV_CPU_FLAG_MMX)
+#endif
__asm__ volatile ("emms" ::: "memory");
}
#elif HAVE_MMX && HAVE_MM_EMPTY
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] doc/demuxers: add some concat demuxer script examples
On 26.01.2016 09:09, Tobias Rapp wrote: On 25.01.2016 13:22, Nicolas George wrote: Le decadi 30 nivôse, an CCXXIV, Tobias Rapp a écrit : Attached patch adds some example scripts for the concat demuxer to the documentation. Well, I maintain the code, not really the documentation. >From 5ffc11e8139476d18cd2eaa28338adb0dda80999 Mon Sep 17 00:00:00 2001 From: Tobias Rapp Date: Tue, 19 Jan 2016 15:42:33 +0100 Subject: [PATCH] doc/demuxers: add some concat demuxer script examples Signed-off-by: Tobias Rapp --- doc/demuxers.texi | 21 + 1 file changed, 21 insertions(+) diff --git a/doc/demuxers.texi b/doc/demuxers.texi index fb1e4fb..3900272 100644 --- a/doc/demuxers.texi +++ b/doc/demuxers.texi @@ -214,6 +214,27 @@ The default is 0. @end table +@subsection Examples + +Example script which uses absolute filenames and includes some comments: I am not sure that "which" is the most idiomatic here, "that" sound better, but I am not a native speaker. I can also avoid which/that by "itemize"-ing the examples similar to other example sections within the documentation. Attached an updated version of the patch. [...] Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: Questionable libav code
On Tue, 2 Feb 2016 14:31:20 -0800
Ratin wrote:
> libavcodec has codes like this one (utils.c):
>
> static AVPacket *add_to_pktbuf(AVPacketList **packet_buffer, AVPacket *pkt,
>AVPacketList **plast_pktl)
> {
> AVPacketList *pktl = av_mallocz(sizeof(AVPacketList));
> if (!pktl)
> return NULL;
>
> if (*packet_buffer)
> (*plast_pktl)->next = pktl;
> else
> *packet_buffer = pktl;
>
> /* Add the packet in the buffered packet list. */
> *plast_pktl = pktl;
> pktl->pkt = *pkt; <===
> return &pktl->pkt;
> }
>
> Here a struct variable is meant to be copied over via assignment, is that
> 100% correct to always work the way was intended? Given that the struct
> pkt is a big struct which has raw bytes that are malloc'd. I was always
> trained to avoid such struct assignment operations. What do people think?
There is no problem at all here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] sdl: Remove AVPicture usage
On Tue, 2 Feb 2016 23:41:59 -0300 James Almer wrote: > On 2/2/2016 11:17 PM, Timothy Gu wrote: > > On Mon, Feb 01, 2016 at 07:04:06PM -0800, Timothy Gu wrote: > >> --- > >> libavdevice/sdl.c | 10 ++ > >> 1 file changed, 6 insertions(+), 4 deletions(-) > > > > Set pushed. > > > > Timothy > > You sent this set last night. There was no reason to push it in a hurry > without waiting for a review. While I'm all for reviews, this set is rather inoffensive, and there are much messier and more controversial patches pushed without even sending them to the ML. Do we even have a consistent policy here? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
