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

[burek]

[01:21:02 CEST] <philipl> BtbN: No strong opinion. Do we want lots of different npp filters or one multi-role npp filter?
[09:32:37 CEST] <kurosu> atomnuker, err... after what I've said, I suppose you're speaking about magnitude, in which case I still think they are useless, as Paul said his transform is dc-only in that case
[09:37:09 CEST] <atomnuker> sure, but you don't know how many bits you'd potentially need to skip to get to the next DC value, unless prores does a dirac thing where each block is of the same size
[09:54:51 CEST] <kurosu> you have random access to slices, and a slice bitstream is first dcs, then acs
[09:55:08 CEST] <kurosu> so you don't need to know about acs to get to next dcs
[09:55:27 CEST] <kurosu> it really looks like they intended 1/8 decoding to be efficient
[10:12:11 CEST] <durandal_1707> is there list of codecs that are being fuzzed?
[10:15:48 CEST] <kurosu> I remember https://github.com/google/oss-fuzz and I guess issues are sent to ffmpeg-security
[10:15:53 CEST] <kurosu> or some such
[10:16:14 CEST] <kurosu> https://github.com/google/oss-fuzz/blob/master/projects/ffmpeg/project.yaml
[10:16:43 CEST] <kurosu> because security, exposed bugs are I guess not going to be listed on a public page
[12:08:36 CEST] <BtbN> philipl, it just seems odd to have a rotate filter, that can only do multiples of 90°
[12:08:44 CEST] <BtbN> I'd much rather have an actual transpose filter
[12:09:07 CEST] <BtbN> That can then maybe get a few extra modes compared to sw transpose
[14:06:46 CEST] <BtbN> Does configure not support spaces in paths passed to extra-*flags? I have stuff in C:/Program Files and it explodes, and no attempt at escaping it works.
[15:11:34 CEST] <thardin> was av1 i webm standardised yet?
[15:11:51 CEST] <JEEB> the mp4 thing seemed to get a 1.0.0 tag
[15:12:00 CEST] <JEEB> https://github.com/AOMediaCodec/av1-isobmff/releases/tag/v1.0.0
[15:12:43 CEST] <JEEB> matroska one doesn't seem to have been updated since 22 days ago
[15:12:46 CEST] <JEEB> https://github.com/Matroska-Org/matroska-specification/blob/av1-mappin/codec/av1.md
[15:14:39 CEST] <thardin> hum hum
[15:16:59 CEST] <thardin> might as well ask here: we were having discussions in #freedv what might be a suitable video codec in the 5 kbps range. any ideas? I gave x264 a go, after stripping its output of some crap. works OK at 5fps half QCIF. but maybe AV1 can do better?
[15:45:48 CEST] <cone-259> ffmpeg 03Paul B Mahol 07master:d8ad8fd8bd25: avcodec/qdmc: check return code of ff_fft_init()
[15:51:21 CEST] <cone-259> ffmpeg 03Paul B Mahol 07master:af71a3ff3eb8: avcodec/wcmv: fix output on big-endian with rgb565 format
[16:48:38 CEST] <kurosu_> thardin, in case nobody replied about av1, very likely better at 5kbps by increasing resolution, though it depends on the encoder & real time requirements
[16:48:51 CEST] <kurosu_> 256x192 at 5fps might be doable, I don't know
[16:49:03 CEST] <BtbN> why would anyone do that though
[16:49:29 CEST] <kurosu_> that low of a resolution? av1?
[16:49:39 CEST] <BtbN> 256x192 at 5fps
[16:49:52 CEST] <kurosu_> I think 5kbps is the actual constraint, then you do with it
[16:50:58 CEST] <kurosu_> But 5kbps is indeed incredibly low by most network connection rates
[16:51:28 CEST] <BtbN> The only thing I could think of is this new IoT Mobile Data network they are building. It has max data rates in that region
[16:52:15 CEST] <kurosu_> "FreeDV: Open Source Amateur Digital Voice" => HF radio
[16:52:33 CEST] <BtbN> https://en.wikipedia.org/wiki/LoRa that's what they are right now setting up in Germany
[16:52:35 CEST] <kurosu_> they mention audio at 1.7kbps
[16:52:40 CEST] <BtbN> the article is really bad though
[16:52:42 CEST] <thardin> https://www.qsl.net/wa6nut/FreeDVplusVideo  that's the thing to beat
[16:52:45 CEST] <BtbN> No mention of the speed
[16:53:03 CEST] <thardin> the video part is entirely analog. like SSTV mixed with hellschreiber
[16:53:36 CEST] <thardin> LoRa is proprietary
[16:53:58 CEST] <kurosu_> ok then most codecs may not buy you that much if quality is very low to begin with
[16:54:21 CEST] <thardin> quality doesn't need to be super great tho
[16:54:43 CEST] <kurosu_> you could prototype this by encoding with x265 which should give you a lower bound of what to expect
[16:54:46 CEST] <BtbN> The video quality of that FreeDV thing looks even worse than I expected lol
[16:54:48 CEST] <kurosu_> as you did with x264
[16:55:02 CEST] <thardin> BtbN: yeah compared to the audio quality freedv gives you it p bad
[16:55:37 CEST] <thardin> x265 would likely be better yes. ideally one would stay away from patent problematic things. AMBE+2 is already a problem
[16:55:51 CEST] <thardin> on the other hand AVC and HEVC both have open specs at least, unlike AMBE
[16:56:07 CEST] <kurosu_> I guess, that's why I say "prototype"
[16:56:18 CEST] <kurosu_> though you can use aomenc today
[16:56:27 CEST] <thardin> ye. gotta turn the 'ol inspiration into perspiration
[16:58:55 CEST] <thardin> the results I got from x264 with intra refresh is already inspiring
[16:59:35 CEST] <BtbN> I guess the question is how well it handles the inevitable gabling analog transmission does to it
[16:59:43 CEST] <thardin> yes
[17:00:04 CEST] <thardin> one probably wants to do bitrate slicing, and code the lower resolution stuff with more FEC
[17:00:41 CEST] <kurosu_> that's not done at the phy level ?
[17:01:12 CEST] <thardin> depend on how you define phy
[17:01:23 CEST] <thardin> somewhere between the waveform and codec let's say
[17:01:54 CEST] <philipl> BtbN: fair point.
[17:02:03 CEST] <thardin> the main dev, david rowe vk5dgr, has written quite a lof of interesting thigns how the modem design and codec design affect eachother
[17:03:01 CEST] <thardin> the current freedv modes are all constant bitrates. but there's no reason why you couldn't do VBR and have a modem with multiple "modes" for that
[17:03:03 CEST] <kurosu_> thardin, to me codec = application layer, I really meant phy or even data link
[17:03:19 CEST] <thardin> OSI model is no use here
[17:03:42 CEST] <thardin> it all has to be very integrated if you want to be able to communicate when the signal is 10 dB below the noise floor
[17:03:46 CEST] <kurosu_> you've probably made away with several layers, I guess
[17:04:37 CEST] <thardin> iirc the latest mode (700D) uses LDPC and multiple carriers in such a way that errors tend to happen for less important bits
[17:04:49 CEST] <kurosu_> ok
[17:06:07 CEST] <thardin> PHY is typically just a normal linear HF (SSB) transceiver
[17:06:21 CEST] <thardin> so you have audio in/out of the 'puter
[17:07:35 CEST] <thardin> it's a bit unfortunate that most transceivers have very narrow filters that can't be changed. like 2.5 kHz bandwidth, which your entire signal has to fit into
[17:08:15 CEST] <thardin> but of course if you're clever you put the less important bits on the band edges, so those with wider sets get better quality :]
[17:09:31 CEST] <BtbN> philipl, I submitted a proper transpose_npp to the list. In my test it behaves identical to normal transpose. It just somehow slightly blurrs the image in the process, even though it should be a pixel perfect operation
[17:09:50 CEST] <thardin> gym time
[17:11:49 CEST] <philipl> BtbN: huh - blur is weird.
[17:12:19 CEST] <BtbN> Setting the interpolation to nearest neighbour also doesn't fix it
[17:12:44 CEST] <BtbN> I feel like it might be a one-off error somewhere, that scales the image down and up again by one pixel, or something like that
[17:13:08 CEST] <philipl> in their code?
[17:13:14 CEST] <philipl> so even a mirror flip is blurred?
[17:13:18 CEST] <BtbN> In the filter
[17:13:25 CEST] <BtbN> It doesn't support a mirror flip :D
[17:13:55 CEST] <BtbN> cclock_flip is the most simple action it can do, as it skips the rotate stage entirely, and only calls Transpose
[17:14:10 CEST] <BtbN> And I think that one indeed does not blur, but it's so subtle it's hard to tell for sure
[17:17:36 CEST] <philipl> BtbN: Code looks reasonable. So just to be clear - you think the off-by-one is in libnpp or in your code?
[17:17:49 CEST] <BtbN> no idea
[17:18:08 CEST] <philipl> I don't really see how an off-by-one would show up in your code.
[17:18:23 CEST] <BtbN> The shifting it does in _rotate is the most likely candidate probably
[17:18:35 CEST] <BtbN> I don't understand it at all, nvidia wrote it
[17:18:50 CEST] <philipl> Yeah, looking at that now. Maybe the subtract 1 isn't such a great idea :-)
[17:19:37 CEST] <philipl> Does it blur if you rotate a square image?
[17:19:49 CEST] <BtbN> haven't tried that yet
[17:31:37 CEST] <BtbN> nah, everything seems to be fine. Probably just VLC doing very slightly different scaling on one of my screens
[17:32:22 CEST] <BtbN> Switching the default scaling algorithm from cubic to nn though. There is absolutely no difference between them, but cubic is like 10 times slower
[17:39:59 CEST] <cone-259> ffmpeg 03Paul B Mahol 07master:a5278b672aaa: avcodec: add RemotelyAnywhere Screen Capture decoder
[17:40:00 CEST] <cone-259> ffmpeg 03Paul B Mahol 07master:068412f2e88b: avcodec/rscc: fix decoding of some iscc files
[17:48:36 CEST] <philipl> BtbN: it makes sense. for a 90 rotation you should never interpolate. So the cubic is just wasted CPU cycles
[17:49:03 CEST] <philipl> but ok. Code looks alright, so if there's no blur - good to go.
[17:49:28 CEST] <BtbN> Yeah, it's weird they included an interp_algo option at all
[17:50:05 CEST] <BtbN> It's also not blindly copied from scale_npp
[17:53:11 CEST] <BtbN> I really like this staged design, and would kinda like to split it out for easier re-use without code duplication
[18:01:37 CEST] <atomnuker> durandal_1707: you forgot to unindent a switch on the remotelyanywhere decoder
[18:03:01 CEST] <durandal_1707> atomnuker: what?
[18:04:04 CEST] <atomnuker> ah, nvm
[21:42:37 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:aaa3f115d8e4: avcodec/cook: decoder supports init_cleanup capability
[21:42:37 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:aa76bdea1fd5: avcodec/cscd: decoder supports init_cleanup capability
[21:42:37 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:94437e440925: avcodecc/cscd: fix some obvious style issues
[21:42:37 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:ea6f61025eac: avcodec/dsicinvideo: decoder supports init_cleanup capability
[21:42:37 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:ae227fa1f27e: avcodec/fic: change class name to more correct one
[21:42:38 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:15a5f49c0b6b: avcodec/flashsv: check return value of flashsv_decode_init()
[21:42:38 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:1f71f0a3129a: avcodec/fmvc: use correct pixel format on big-endian for 16 bpp
[21:42:39 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:0d37823c836d: avcodec/interplayacm: decoder supports init_cleanup capability
[21:42:39 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:e8b27b82d077: avcodec/mscc: decoders supports init_cleanup capability
[21:42:40 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:1e09dd96fe5c: avcodec/on2avc: decoder supports init_cleanup capability
[21:42:41 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:86e7e7816b24: avcodec/tscc: check av_frame_alloc() for failure
[21:42:43 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:51a087771bd7: avcodec/tscc: decoder supports init_cleanup capability
[21:42:43 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:337b9e190ba0: avcodec/ulti: fix minor style issue
[21:42:44 CEST] <cone-402> ffmpeg 03Paul B Mahol 07master:6e15495bcb20: avcodec/zmbv: decoder supports init_cleanup capability
[00:00:00 CEST] --- Sun Sep  9 2018