[Ffmpeg-devel-irc] ffmpeg-devel.log.20140615

[burek]

[00:01] <J_Darnley> Better instruction order?
[00:02] <kierank> inlining perhaps
[00:07] <kurosu> dead code elimination
[00:07] <kurosu> I suspect the macros have written to achieve their goal, not to be efficient
[00:08] <kurosu> *the asm macros were
[00:08] <kurosu> eg the filter coeffs loaded into specific regs without much care about the fact other regs were unused
[00:09] <kurosu> but I can understand pierre-edouard
[00:10] <kierank> I need to find an avx2 machine
[00:10] <kierank> I think I have one somewhere
[00:11] <cone-576> ffmpeg.git 03Ronald S. Bultje 07master:ada8f9c046c8: swr: remove obsolete function prototypes.
[00:21] <smarter> kierank: don't expect me to comment on asm stuff :p
[00:21] <kierank> smarter: i mean comment on the patch to play the broken sample
[00:21] <smarter> ah I didn't see that
[00:21] <kierank> there were also comments on #libav-devel
[00:25] <smarter> kierank: looks OK to me
[00:25] <smarter> didn't see any comment on #libav-devel
[00:26] <kierank> from elenril there was a comment
[00:26] <smarter> It might be a good idea to do something similar for other checks that do not prevent decoding, but maybe it's better to annoy people into fixing their encoder :p
[00:26] <kierank> kurosu: any idea how to do packusdw in sse2
[00:27] <kierank> because then i think at least one function is convertable
[00:28] <kierank> also found some double splats
[00:29] <kierank> hmm he does that a lot for some reason
[00:29] <jamrial> https://stackoverflow.com/questions/11024652/simulating-packusdw-functionality-with-sse2 first answer
[00:30] <kierank> jamrial: yeah but *stackoverflow* :)
[00:30] <jamrial> it's intrinsics, but changing that with actual asm is trivial
[00:30] <jamrial> hey, if it works :P
[00:30] <jamrial> didn't try it, though
[00:31] <J_Darnley> kierank: I think I wrote one in yadif
[00:33] <kierank> i wonder if it's worth moving it to x86util
[00:33] <jamrial> if it's used in more than one file then yes
[00:35] <J_Darnley> Yes: libavfilter/x86/yadif-16.asm
[00:35] <kierank> yeah i found it
[00:35] <J_Darnley> line 64
[00:51] <kierank> hmm my patch is broke
[00:59] <kierank> I think he's actually trying to do splatw
[01:07] <BBB> Im wondering whats uglier, non-static functions or static dead code
[01:07] <BBB> ...
[01:13] <jamrial> if you mean swr, prototypes are going to be needed for yasm, so might as well add them now as a solution for the msvc failures
[01:14] <BBB> I suppose
[01:15] <BBB> I would just give them ff_ prefixes, not swri_
[01:15] <BBB> since theyre local within the lib and we want them to be stripped
[01:28] <jamrial> michaelni suggested swri. i can resend the patch using ff_ if that's better
[01:35] <michaelni> swri should be removable 
[01:35] <michaelni> or am i missing something ?
[01:35] <michaelni> i mean removeable like ff_
[01:35] <michaelni> swr_* should be exportet
[01:36] <michaelni> swresample_dsp* should be renamed 
[01:36] <michaelni> it matches neither suggestion
[01:39] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:86a9370e2b91: avformat/mpc: attempt to allocate a packet that is not smaller than the data inside it
[01:40] <cone-576> ffmpeg.git 03James Almer 07master:7f4dfbd0809d: swr: add prototypes for resample dsp functions
[01:41] <michaelni> currently:   "global: swr_*; ff_*; swresample_*;"
[01:41] <michaelni> so it wont export swri*
[01:45] <BBB> oh swri is internal
[01:45] <BBB> then its ok
[01:46] <BBB> kinda weird but ok
[01:47] <BBB> who calls vzeroupper in inline avx?
[01:49] <BBB> anyway I dont feel like removing inline today, maybe some other time
[01:49] <BBB> Ill go watch football for another few minutes :)
[04:28] <cone-23> ffmpeg.git 03Michael Niedermayer 07master:103f9c261a68: avcodec/indeo5: Fix infinite loop in skip_hdr_extension()
[04:28] <cone-23> ffmpeg.git 03Michael Niedermayer 07master:73d820ee1eb0: avcodec/xbmdec: remove dependancy on zero padding on input packet
[04:33] <michaelni> jamrial, as you are maintainer of a few things, you should have op in in #ffmpeg-devel too
[04:40] <jamrial> michaelni: thanks!
[05:39] <michaelni> kurosu, you have contributed quite a bit of code and asm to ffmpeg, do you want to maintain some of that? if so dont hesitate to send a patch that adds you to maintainers
[05:57] Action: Timothy_Gu thinks that michaelni is becoming a MAINTAINERS maniac.
[06:09] <llogan> now that's an odd message in -devel
[06:09] <llogan> setting mod bit
[10:48] <wm4> did that yadif relicensing some time ago actually work out, i.e. did the contributors get paid?
[10:49] <kurosu> michaelni, I appreciate the consideration, but I'm not sure about it
[10:49] <kurosu> I may be kind of unreliable as a maintainer, in particular for reviews in due time
[10:53] <kurosu> though you probably need the relief, comic or not
[11:11] <J_Darnley> wm4: yes
[11:11] <J_Darnley> well I did
[11:15] <wm4> nice
[13:14] <cone-859> ffmpeg.git 03Christophe Gisquet 07master:56a795e34fb7: aandcttab: fix spelling
[13:14] <cone-859> ffmpeg.git 03Christophe Gisquet 07master:2a1158ff3b29: fate: yadif: add >8 bit tests
[13:18] <michaelni> kurosu, maybe you want to add yourself as co maintainer for something ? like x86 asm ? then being sometimes/often unavailable shouldnt be a problem
[13:31] <cone-859> ffmpeg.git 03Christophe Gisquet 07master:91076128185e: x86util: add and use RSHIFT/LSHIFT macros
[13:32] <kurosu> michaelni, ok, why not
[13:32] <kurosu> I'll see about that later today
[13:33] <michaelni> ok, thanks
[14:17] <cone-859> ffmpeg.git 03Ronald S. Bultje 07master:083cd3d1f771: swr: compile mmx2 s16p functions only on x86-32.
[14:48] <BBB> kurosu: did you fuzz the unsafe bitstream reader stuff for huffyuv under valgrind or so?
[14:48] <BBB> kurosu: or asan
[14:48] <BBB> kurosu: Im fine with that if were convinced we have adequate manual bitstream overread protection
[14:48] <BBB> kurosu: but we want to make sure were not missing anything obvious I guess
[14:50] <kurosu> BBB: nope, though the loops check every 2 samples if end of bitstream was reached
[14:50] <kurosu> but indeed I haven't checked and I don't feel completely safe there
[14:50] <BBB> whats the max size of a sample?
[14:50] <kurosu> 32bits or 3*11 depending on how you look at it
[14:50] <kurosu> so within padding
[14:51] <BBB> hmk
[14:51] <BBB> should be ok
[14:51] <kurosu> yeah, should
[14:51] <kurosu> but fuzzing might be better
[14:51] <BBB> maybe ask michealnis contacts at google to fuzz it for you at their servers
[14:52] <kurosu> I just felt encouraged when mentionning this to michaelni and he hadn't noticed and it made sense
[14:53] <kurosu> michaelni, googlz plz fuzz ? ^
[14:57] <BBB> hehe :)
[15:00] <kurosu> I bet with the experiment on huffyuv, some lossless codecs could be made 10-30% faster
[15:00] <kurosu> huffyuv is 30-40% faster with all patches applied, compared to some weeks ago
[15:01] <kurosu> *huffyuvdec
[15:07] <kurosu> well, when the data is hot - because obviously the hard drive is the limiting factor here
[15:34] <wm4> there's no xml parser in use in ffmpeg yet, right?
[15:35] <wm4> I see mov.c does some strstr() to "parse" xml, but apparently there's nothing else
[15:41] <Daemon404> please dont give them ideas, wm4 
[15:45] <kurosu> why not? What's a few extra MBs when your debug binary is already 100+ ?
[15:46] <Daemon404> because it is a solved problem, NIHing it is retarded.
[15:47] <kurosu> Daemon404, I was ironical
[15:47] <Daemon404> oh
[15:47] <nevcairiel> I guess we're just lucky that no mainstream format needed XML parsing yet
[15:48] <Daemon404> ttxt!
[15:48] Action: Daemon404 runs
[15:48] <wm4> there are some xml subtitle formats
[15:48] <kurosu> configure and link are the most time consuming things when I work on ffmpeg
[15:48] <wm4> they're all handled with ad-hoc custom parsers
[15:48] <Daemon404> kurosu, configure is, by far, for me
[15:48] <nevcairiel> I said mainstream! :p
[15:48] <kurosu> but i deserve what I get for having a slow laptop under win64 without ssd
[15:48] <Daemon404> configure is like 2x the build time
[15:48] <wm4> smil is pretty mainstream in some parts
[15:48] <wm4> well, in korea (lol)
[15:49] <nevcairiel> Asians also use real media
[15:49] <nevcairiel> They don't count
[15:49] <Daemon404> not asians
[15:49] <kurosu> I was surprised there were no patch for hevc-in-rm
[15:49] <Daemon404> chinese, specifically.
[15:49] <Daemon404> kurosu, nah
[15:49] <kurosu> oh crap, this channel is logged
[15:49] <Daemon404> it will be real video 9
[15:49] <Daemon404> or whatever
[15:49] <kurosu> what have I unleashed on the world
[15:49] <Daemon404> which is conveniently similar to hevc
[15:49] <wm4> kurosu: what have you done
[15:50] <kurosu> rv10 probably died when real networks codec department was bought by intel
[15:50] <Daemon404> ah true
[15:50] <kurosu> well, rv50 in ffmpeg's slang
[16:21] <cone-859> ffmpeg.git 03Christophe Gisquet 07master:9dc17919777a: huffyuvdec: swap code blocks
[16:21] <cone-859> ffmpeg.git 03Michael Niedermayer 07master:e9c477059d78: avcodec/huffyuvdec: assume vlcs can be 32 instead of 31 bits max
[16:23] Action: Daemon404 wonders why huffyuv is getting so much love after a decade
[16:32] <cone-859> ffmpeg.git 03Christophe Gisquet 07master:eb6f6f25dc9f: MAINTAINERS: Add Co maintainer for huffyuv*, rv4*, vc1*
[17:25] <BtbN> How would i add an encoder to ffmpeg that needs an external header which cannot be distributed with ffmpeg because of its license?
[17:29] <Daemon404> BtbN, in configure, make it require "non-free"
[17:29] <Daemon404> to be enabled
[17:29] <BtbN> No, the final binary can be freely distributed. The header can't
[17:30] <Daemon404> huh?
[17:30] <BtbN> The NVENC sdk does not allow redistributing any of its headers
[17:30] <Daemon404> why would you add their header to the git repo anyway
[17:30] <Daemon404> i.e. why would it be an issue
[17:31] <BtbN> because it's not an installable dependency on any distribution.
[17:31] <Daemon404> thats not a good enough reason
[17:31] <BtbN> There is no way to search for it. And it's only a header, no library
[17:32] <Daemon404> its part of the official sdk, and i dont think it is unreasonable to think people who want to compile with said encoder need said sdk
[17:36] <BBB> BtbN: you would carefully document how people can get access to this sdk
[17:37] <BBB> BtbN: and if its really that hard, you probably want to make binaries available that have the sdk dependency in it
[17:37] <Daemon404> the other option is to do a cleanroom rewrite or whatever
[17:37] <BBB> (as in, were built against that header)
[17:37] <Daemon404> like mingw-w64 has for dshow
[17:37] <Daemon404> and stuff
[17:37] <BBB> even then the header would live in its own project, not in ffmpeg
[17:37] <BBB> we dont ship libfdkaac headers
[17:38] <BtbN> BBB, well, the SDK can be freely downloaded from nvidias site. But it's nothing that can be normaly installed via some package manager, just some zip file.
[17:38] <BtbN> Daemon404, hm, how would i rewrite a header without basicaly copying the original?
[17:39] <Daemon404> BtbN, i think its reasonable to expect the compiling user to dl the sdk
[17:39] <Daemon404> if they want that feature
[17:40] <BtbN> would be nice to have the feature included in normal builds though. It doesn't have any dependencies except for that header, so it would just work if the user of a distribution built ffmpeg has a recent enough driver
[17:41] <BtbN> I think i'll just mail nvidia if i can re-license that header into something gpl compatible
[17:41] <Daemon404> lol
[17:41] <Daemon404> good luck with that
[18:01] <cone-859> ffmpeg.git 03Christophe Gisquet 07master:29f427c2397b: huffyuvdec: remove somewhat deprecated code
[18:25] <cone-859> ffmpeg.git 03Michael Niedermayer 07master:153b5fb2fdef: avformat/framecrcenc: print the checksum and size of extradata as well
[18:27] <ubitux> strange vqf-demux test
[18:27] <ubitux> fate-vqf-demux: CMD = md5 -i ... -f framecrc
[18:37] <jamrial> so it's doing an md5 with the framecrc output?
[18:39] <jamrial> it's silly, but technically it still works as intended. a change in the framecrc output will be reflected in the md5 value :P
[18:40] <ubitux> i was wondering because of latest commit
[18:40] <ubitux> (there was a diff in md5 for some reason)
[18:43] <jamrial> the framecrc output for that test is about 2600 lines, so i guess that's why it's using the md5 protocol
[18:43] <jamrial> it probably should instead be "fate-vqf-demux: CMD = crc -i ..." like most other demux tests
[18:45] <ubitux> ah, okay
[19:27] <Timothy_Gu> BtbN: i just read the NVENC license https://developer.nvidia.com/nvidia-video-codec-sdk-license-agreement
[19:28] <Timothy_Gu> It says: Subject to Licensees compliance with the terms of this Agreement, NVIDIA grants to Licensee a nonexclusive, non-transferable, worldwide, royalty-free, fully paid-up license and right to install, use, reproduce, display, perform, modify the Source Code of the Software
[19:28] <nevcairiel> doesnt really change the fact that an external header like this should not be part of ffmpeg git
[19:29] <nevcairiel> and i'm sure someone would find fault in that for not being GPL compatible in some way
[19:46] <ubitux> ok hq3x working
[19:47] <ubitux> vf_hqx.c ’ 538L, hqx project ’ 12201L
[19:51] <BBB> ubitux: very cute
[19:51] <BBB> what about speed?
[19:51] <BBB> (or is that not relevant?)
[19:52] <ubitux> it might be relevant, but this is going to be used for stuff like 320x240 or similar
[19:52] <ubitux> i don't really want to bother
[19:52] <ubitux> i'm adding threading right now
[19:52] <ubitux> that should do.
[19:53] <ubitux> and i still have a bug and a few other things to do
[19:53] <ubitux> also, it might be possible to make the code even simpler
[19:53] <ubitux> i'll probably the final version this week or next w/e
[19:53] <ubitux> +submit
[20:15] <kurosu> ubitux, would you or someone close to you use it, or was it for the fun ?
[20:16] <ubitux> more like a challenge, i don't think i'll use it
[20:16] <ubitux> :p
[20:17] <kurosu> so that was fun
[20:17] <ubitux> mmh
[20:17] <kurosu> my definition of fun stops at simd inloop filter
[20:17] <ubitux> it got me too much angry to actually call it fun but yeah, somehow
[20:43] <cone-859> ffmpeg.git 03Anshul Maheshwari 07master:9a11b33a2d9d: avcodec/dvbsubdec: restructure version check
[20:43] <cone-859> ffmpeg.git 03Anshul Maheshwari 07master:77ade55fe52e: avcodec/dvbsubdec: add AVClass to context
[20:43] <cone-859> ffmpeg.git 03Anshul Maheshwari 07master:fbb59a3bf4c8: avcodec/dvbsubdec: Split save_subtitle_set() out
[21:05] <wm4> ubitux: I know you probably still hate subtitles, but I think this supports some tags your code doesn't: https://aur.archlinux.org/packages/mplayer-microdvd/
[21:05] <ubitux> wat
[21:06] <ubitux> http://b.pkh.me/p0-MicroDVD-36279.patch
[21:06] <ubitux> :/
[21:07] <ubitux> it looks like feature we're supporting
[21:07] <ubitux> mmh
[21:07] <ubitux> +        if (*p == '#') ++p; // Correction By Xaweryz; for subs like {c:$#007FFF}
[21:07] <ubitux> maybe this?
[21:07] <ubitux> (wth)
[21:08] <wm4> lol
[21:08] <ubitux> did you get a bad subtitles file or sth?
[21:08] <wm4> no, https://github.com/libass/libass/issues/110
[21:08] <wm4> someone wants to add microdvd parsing to libass
[21:09] <ubitux> lol
[21:09] <ubitux> well anyway the microdvd code already supports color & stuff
[21:09] <ubitux> i could add the '#' workaround easily if you get me a sample
[21:11] <ubitux> wm4: mpv uses microdvd decoder, right?
[21:12] <wm4> currently the internal one is still preferred
[21:12] <wm4> I'll push a commit to change this
[21:25] <ubitux> great, i found a bug in the original hqx code
[21:34] <wm4> ubitux: copy&paste error?
[21:34] <wm4> or whatever the process is which was used to create the source
[21:34] <wm4> because it's so highly unrolled
[21:34] <ubitux> unrelated to the unrolling
[21:35] <ubitux> it's the rgb->yuv table
[21:35] <wm4> aw
[21:35] <ubitux> it's missing the init for the latest element
[21:35] Action: wm4 still doesn't understand why there's yuv in this
[21:35] <ubitux> so with white in an input i had surprises, sometimes :)
[21:36] <ubitux> like: http://b.pkh.me/pixelart0.png-hq4x.png vs http://b.pkh.me/ff-pixelart0.png-hq4x.png
[21:36] <ubitux> (i let you find the glitch)
[21:36] <ubitux> wm4: because it has difference thresholds
[21:37] <ubitux> (to check if there is a difference with surrounding pixels)
[21:37] <wm4> so it basically uses luminance difference as metric?
[21:37] <ubitux> yes, and also chroma
[21:38] <ubitux> 48 diff in luma, 7 and 6 in u/v
[21:38] <wm4> and I can't spot the glitch
[21:38] <ubitux> look at the skeleton
[21:38] <wm4> oh.
[21:39] <ubitux> btw, i could add an option to make it use ffmpeg internal scaling and use yuv only (zomg faster) but it won't be bitexact with the reference
[21:40] <ubitux> it seems it's already reported... https://code.google.com/p/hqx/issues/detail?id=8 heh.
[21:41] <jamrial> sep 2012. status new. no replies
[21:41] <jamrial> well...
[21:41] <ubitux> :)
[21:51] <michaelni> kierank, ok if i apply the hevc/4k patch or should we keep waiting ?
[21:54] <kierank> Ask smarter
[22:01] <kurosu> kierank, is there a way to identify the encoder that produced that file?
[22:01] <kurosu> because otherwise it seems to let invalid bitstream be decoded
[22:01] <JEEB> what kind of derp did that bitstream seemingly have?
[22:01] <kurosu> and I don't know what that may cause if the origin is not that encoder
[22:02] <kurosu> incorrect vps info
[22:02] <JEEB> ah
[22:02] <JEEB> funny enough the Japanese 4K channel was able to actually do that shit right :P
[22:02] <JEEB> so much that I'm even damn surprised
[22:02] <kurosu> related to reference frames iirc, but I don't think it's related to rps
[22:03] <kurosu> so it is a Japanese DVB-S stream or something ?
[22:03] <JEEB> no
[22:03] <JEEB> kierank has his own sources
[22:03] <JEEB> I've only seen some Japanese ISDB-S samples
[22:04] <JEEB> and those decoded fine with lavvc
[22:04] <JEEB> *lavc
[22:04] <kurosu> ok
[22:04] <JEEB> you'd be surprised with the features they used :3 https://drive.google.com/folderview?id=0BzkZOi5-Ka62NG1aa2RkaUFldzg&usp=sharing#list
[22:04] <JEEB> (check the file that ends with A)
[22:05] <JEEB> 2160p60, HEVC, 10bit, BT.2020 \o/
[22:08] <ubitux> michaelni: could you upload http://b.pkh.me/pixelart0.png and http://b.pkh.me/pixelart1.png to fate-samples/filter?
[22:09] <kurosu> JEEB: is that a H.264 encoder with HEVC syntax ?
[22:10] <michaelni> kierank, i asked smarter long ago if he wants to maintain hevc and he didnt want to. But well, i surely would be very happy if that changed
[22:10] <JEEB> I haven't checked the bit stream too much, but I wouldn't be surprised if it was using 64x64 blocks
[22:11] <michaelni> smarter, is "0614 20:26 Kieran Kunhya   (2.0K) [FFmpeg-devel] [PATCH] hevc: Fix 4K sample video" ok to apply ?
[22:15] <kierank> kurosu: came from a European football match
[22:18] <michaelni> ubitux, uploaded
[22:19] <ubitux> michaelni: thx
[22:21] <llogan> it has Golden Axe, but is missing Altered Beast.
[22:26] <kurosu> michaelni, about the patch I didn't send, I'm holding onto it because of the end psnr value
[22:27] <kurosu> I would have expected infinite psnr, but seeing 38.xdB, I'm wondering if that's due to colorspace conversions here or there
[22:28] <kurosu> going back some commits still yield this, so I'm inclined to think it's the reaseon
[22:28] <michaelni> does it compare yuv420 or bgr24 ?
[22:29] <kierank> kurosu: do you know of any good free hevc analysers
[22:30] <kurosu> michaelni: http://pastebin.com/LRVTc9eF
[22:31] <kurosu> kierank, no
[22:32] <kierank> I am curious now to see if JEEB's samples are just h264 encoders writing an hevc bitstream
[22:32] <kurosu> kierank, just a humorous remark
[22:32] <kierank> that happened in the early days of h264
[22:32] <kurosu> actually I don't have a way to check either
[22:32] <llogan> i don't understand why carl told a user to not use -an in first pass encoding w/ libx264.
[22:32] <kierank> there is one very expensive encoder that did that
[22:33] <kurosu> but people may not had time to actually create a real hevc encoder
[22:33] <kierank> excactly
[22:34] <llogan> why would encoding (or not encoding) the audio in the first pass matter? (i haven't read the ticket he mentined though since it was so long)
[22:35] <kurosu> I know some companies boasting H264 devices, where the motion was only halfpel - but that may have been like 5+ years ago
[22:35] <kierank> i've seen that too and with only 8x8 blocks
[22:35] <kurosu> nowadays, some do the same with hevc
[22:36] <kurosu> I even heard of a company showing their encoder, while it was actually an offline encoding reencoded to H.264 lossless or something
[22:37] <kurosu> at IBC or NAB or whatever such trade show
[22:37] <kierank> many do that
[22:43] <JEEB> anyways, I need to grab more samples of that Japanese channel, since they're going to be airing the world cup
[22:48] <kurosu> probably I shouldn't be asking but... is that not encrypted ?
[22:48] <JEEB> it uses basic Japanese DTV encryption
[22:49] <JEEB> (all of the DTV in Japan except for 1seg is encrypted)
[22:49] <JEEB> so no, it's not a paytv channel
[22:50] <kurosu> I really meant encrypted only
[22:50] <kurosu> I didn't know there were different encryptions with different levels of complexity
[22:50] <JEEB> well, encryption usually means that something is paytv
[22:50] <JEEB> at least in the west
[22:51] <JEEB> which is what this is not
[22:51] <JEEB> it's just that everything except for 320x180 at 15/1.001 mobile broadcast is encrypted
[22:51] <JEEB> (1seg)
[22:52] <JEEB> the non-paytv Japanese DTV encryption was fully software'ized a bit more than a year ago
[22:52] <JEEB> http://repo.or.cz/w/soft_arib_std_b25.git
[22:52] <wm4> wait, so even public broadcast is encrypted?
[22:52] <JEEB> yes
[22:53] <JEEB> _everything_ is encrypted, thanks to hollywood pressure
[22:53] <JEEB> except that crappy mobile broadcast that even mobiles are moving away from
[22:53] <kierank> wm4: there is drm but not CA I guess
[22:54] <wm4> terrible
[22:54] <JEEB> also funny enough the official devices and software are meant to keep that content under extra locks on users' devices
[22:54] <JEEB> even the mobile airing
[22:54] <JEEB> thankfully it didn't take too long for "research only" hardware to pop up
[22:55] <JEEB> and given that B-CAS cards are just normal smart cards it wasn't too hard to implement the descrambling
[22:55] <kurosu> Nice, all-zeros encryption keys
[22:55] <kierank> JEEB: what channel is that?
[22:55] <kierank> which you recorded
[22:55] <JEEB> kierank, channel 4k
[22:56] <kurosu> except for NHK
[22:56] <JEEB> ch502
[22:56] <JEEB> kurosu, I think those without valid keys are the paytv channels
[22:56] <kurosu> yea, still I guess someone was able to bruteforce at least NHK key
[22:57] <JEEB> nah, those just weren't hardened in any way
[22:57] <JEEB> paytv actually means you have to poke at the internals
[22:57] <JEEB> since the key is passed upon you via the card ID
[22:57] <JEEB> and then stored on the card
[22:58] <JEEB> kierank, this one http://www.nextv-f.jp/information/index.html
[22:58] <kierank> ok i think it's an ntt
[22:59] <JEEB> NHK is participating, yes
[22:59] <JEEB> it seems to be a group effort
[23:00] <JEEB> NTV, SkyPerfect TV, TBS, TV Tokyo, NHK and WOWOW are giving out content at least
[23:02] <JEEB> and yeah, starting member companies are listed on the index page and include a whole lot of corps
[23:02] <JEEB> including those I just mentioned
[23:02] <JEEB> and hardware makers such as Sharp, Sony, Toshiba, Panasonic
[23:03] <JEEB> Fujitsu, NEC, NTT
[23:03] <JEEB> and yes, I totally read your NTT as NHK :P
[23:03] <JEEB> getting late >_>
[23:10] <michaelni> kurosu, the psnr looks like colorspace convert related, yes, i think you can post the patch and ill apply it unless someone wants to add support for bgr based tests
[23:20] <smarter> kierank: why did you submit a different patch to ffmpeg and libav?
[23:20] <kierank> smarter: there some additional checks in ffmpeg iirc
[23:21] <kierank> the behaviour was different
[23:21] <smarter> ah, maybe ffmpeg already has a patch to tolerate the error on the sps
[23:22] <smarter> indeed
[23:23] <smarter> michaelni: the hevc patch is OK
[23:23] <michaelni> smarter, thanks
[23:28] <cone-859> ffmpeg.git 03Carl Eugen Hoyos 07master:b67bcd784dde: Fix compilation on ppc64 and ppc with pic if gas-preprocessor is installed.
[23:28] <cone-859> ffmpeg.git 03Michael Niedermayer 07master:c1b15c16ef74: avformat/smoothstreamingenc: Use av_mallocz_array()
[23:28] <cone-859> ffmpeg.git 03Kieran 07master:bc21260e643c: hevc: Fix 4K sample video
[23:29] <smarter> kierank: I'll send an updated patch to libav with the missing change from ffmpeg
[23:29] <smarter> (which already checks sps->temporal_layer[i].num_reorder_pics > MAX_DPB_SIZE - 1)
[23:29] <kierank> thanks
[23:34] <kurosu> michaelni, confirmed it, when having an intermediate rgb file, input/output perfectly match
[23:38] <jamrial> kurosu: same happens with other ffhuff tests. also zlib
[23:39] <kurosu> jamrial, I hadn't noticed
[23:39] <kurosu> the yuv422 test case confused me
[23:39] <kurosu> the psnr is perfect, but I suspect this is because of point resampling
[23:40] <kurosu> had I look one file further, I wouldn't have needed to confirm it
[23:40] <kurosu> *looked
[23:41] <jamrial> i noticed the other day when i added a cinepak test to play with vsynth, and the result wasn't lossless. then started checking other ref files and quite a lot of formats were the same
[23:42] <jamrial> for that matter, cinepak enc maintainer should probably add a vsynth test
[23:42] <jamrial> though it's so absurdly slow i don't know who would use it as is
[23:44] <kurosu> what, not tented to add dsp assembly for a 25yo codec ? :)
[23:45] <kurosu> (probably more related to the r/d exploration than anything, but I was kidding)
[23:45] <jamrial> heh
[23:47] <jamrial> actually, i'm confusing things. cinepak is lossy. i'm not sure how i ended up looking at lossless refs and finding that about ffhuff by playing with that
[00:00] --- Mon Jun 16 2014