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

[burek]

[00:18:17 CEST] <cone-704> ffmpeg 03Rostislav Pehlivanov 07master:6213cf73945d: atrac9dec: relax gradient value requirements
[00:18:18 CEST] <cone-704> ffmpeg 03Rostislav Pehlivanov 07master:ea82ff81e4ae: atrac9dec: implement LFE channel decoding
[00:18:36 CEST] <atomnuker> now all files from thealexbarney's crazy testset decode correctly!
[00:24:41 CEST] <JEEB> nice
[05:18:32 CEST] <atomnuker> holy shit
[05:19:09 CEST] <atomnuker> on the vita version of va11 hall-a some tracks have been converted to .ogg with ffmpeg
[05:19:15 CEST] <atomnuker> as in ffmpeg.c
[05:19:27 CEST] <atomnuker> from the official released soundtrack
[05:19:51 CEST] <atomnuker> how do I know this? they forgot to disable the theora video stream ffmpeg will create by default for .ogg files
[05:30:29 CEST] <TD-Linux> lul. let me check the pc version. what does it take to fix that wonderful ffmpeg.c behavior
[05:49:02 CEST] <cone-889> ffmpeg 03Rostislav Pehlivanov 07master:964819fefdd1: atrac9dec: clean up code slightly
[05:49:12 CEST] <atomnuker> disable theora as the default video codec for .ogg
[06:01:34 CEST] <TD-Linux> can ffmpeg.c discern between .ogv and .ogg?
[06:03:34 CEST] <atomnuker> yeah, I think so, it knows the difference between .mka and .mkv
[06:41:57 CEST] <cone-889> ffmpeg 03Gyan Doshi 07master:26dc76324564: ffmpeg: add correct field for raw pts in -progress report
[12:29:20 CEST] <durandal_1707> http://nico-lab.net/vmaf_score_using_deinterlace-denoise_filters/
[12:32:01 CEST] <thardin> moon language
[12:35:35 CEST] <kierank> iiuc vmaf sucks on sports
[12:35:37 CEST] <kierank> with grass
[12:35:47 CEST] <kierank> but netflix doesn't do sports so their test corpus doesn't notice
[12:50:38 CEST] <LigH> Hi.
[12:50:50 CEST] <durandal_1707> hi
[12:51:16 CEST] <LigH> Is there a common naming convention between a library to be linked into ffmpeg and the related pkg-config file (*.pc)?
[12:53:14 CEST] <LigH> Specifically, is it necessary to have a lin/pkgconfig/liblensfun.pc to link lib/liblensfun.a ?
[12:53:25 CEST] <LigH> *lib/
[12:56:27 CEST] <LigH> The building of lensfun generates lib/pkgconfig/lensfun.pc (without "lib") instead. That seems to be part of an issue.
[12:56:46 CEST] <jkqxz> It depends on the convention for that library.  In the case of lensfun it looks like the pkg-config component is called "lensfun".
[12:59:13 CEST] <LigH> wiiaboo (author of the media-autobuild_suite) believes that ffmpeg expects a liblensfun.pc instead:
[12:59:16 CEST] <LigH> https://github.com/jb-alvarado/media-autobuild_suite/issues/899#issuecomment-416375759
[12:59:51 CEST] <jkqxz> That's checked at <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=3cf9412947b332d49348a15ed0ed7eba53ddf306;hb=HEAD#l6070> - the second argument to the (require|check)_pkg_config call is the name of the pkg-config component (the first argument is the ffmpeg config name).
[13:00:40 CEST] <jkqxz> RiCON:  ^
[13:03:03 CEST] <LigH> Well, maybe there is a different reason why pkg-config cannot find a component which has been built and installed moments ago. I do not know the suite inwards, I'm only using it (and meddling with it a little, sometimes).
[13:03:17 CEST] <LigH> I don't know shell script syntax, only guessing.
[13:03:28 CEST] <LigH> Trial and error.
[13:04:37 CEST] <LigH> And unfortunately, support for the suite starts decreasing.
[13:16:11 CEST] <LigH> The error message is: "ERROR: lensfun not found using pkg-config"; so somehow I believe the problem is not the name, but a missing registration during its installation after building?
[13:18:41 CEST] <nevcairiel> all the files would of course also have to be put into the correct place so that pkg-config can find it
[13:19:34 CEST] <nevcairiel> there is no "registration" outside of having a lensfun.pc somewhere that pkg-config is going to check for it
[13:31:07 CEST] <BBB> jkqxz: did you see the pleas yesterday for you to please please attend VDD?
[13:31:24 CEST] <LigH> So maybe pkg-config doesn't know to look in that directory...
[13:31:32 CEST] <BBB> kierank: does it? that would be interesting to bring up on their bug tracker
[13:32:30 CEST] <kierank> BBB: ateme gave a presentation saying it does
[13:32:37 CEST] <kierank> and I would take ateme's word for it
[13:32:48 CEST] <BBB> interesting
[13:32:49 CEST] <kierank> https://www.theiabm.org/wp-content/uploads/2018/05/Ateme-OTT-event.pdf
[13:32:54 CEST] <kierank> unfortunately many marketing slides
[13:34:01 CEST] <LigH> (Rémoulade is spoiled)
[13:34:08 CEST] <BBB> that might actually be related to an AQ-related weighting issue I brought up with them earlier
[13:34:14 CEST] <BBB> looks like it, at least
[13:34:31 CEST] <BBB> you can see that the audience on top in the left picture has more details than on the right
[13:35:18 CEST] <BBB> and the weighting (suspected) bug is that I dont think the weighting of different parts of a frame are different
[13:35:30 CEST] <BBB> for different frames in a sequence, the weighting *is* different
[13:35:45 CEST] <BBB> so I think they shouldve done that intra-frame also
[13:36:01 CEST] <BBB> (this is supposedly very difficult to do, and Im not smart enough to be able to do it myself :-( )
[13:36:08 CEST] <jkqxz> BBB:  I did; I'm afraid I won't make it this year.
[13:37:03 CEST] <BBB> sorry to hear :(
[13:43:44 CEST] <durandal_1707> give me something easy to do!
[14:36:29 CEST] <LigH> Regarding lensfun, I found a linker error, I believe. May I show you the tail of ffbuild/config.log?
[14:37:50 CEST] <durandal_1707> yes, use pastebin or similar
[14:39:14 CEST] <LigH> https://pastebin.com/CBe4jc2i
[14:39:32 CEST] <LigH> undefined reference to `_imp__g_utf8_skip'
[14:42:18 CEST] <jamrial> that seems to be from glib2
[14:42:30 CEST] <LigH> Complete archive of MABS logs = https://0x0.st/stTc.zip
[14:42:32 CEST] <nevcairiel> the usual reason for such problems is that the libraries .pc file is incomplete
[14:43:46 CEST] <nevcairiel> if it needs glib, then the .pc file needs to indicate that
[14:43:50 CEST] <jamrial> what do you get from running " pkg-config --libs lensfun" vs "pkg-config --libs --static lensfun"?
[14:43:51 CEST] <nevcairiel> otherwise how is ffmpeg to know
[14:45:28 CEST] <LigH> https://pastebin.com/iabRDHcn
[14:46:28 CEST] <jamrial> well, there you go. you have a static build of lensfun, so simply run configure with --pkg-config-flags=--static
[14:46:53 CEST] <nevcairiel> the config.log shows it actually tried to link with glib
[14:46:55 CEST] <nevcairiel> it just didnt work
[14:47:43 CEST] <LigH> Could it be a required-version conflict? MSYS2 packages had them sometimes.
[14:47:53 CEST] <nevcairiel> probably because its windows and the symbol is not named _imp__g_utf8_skip, but just _g_utf8_skip
[14:48:26 CEST] <Yagiza> Is this a better place to discuss RTP?
[14:49:51 CEST] <nevcairiel> https://github.com/Alexpux/MINGW-packages/issues/988 seems vaguely related
[14:50:02 CEST] <Yagiza> How can I specify sdp_flags=custom_io option to make it work?
[14:50:04 CEST] <nevcairiel> static linking everything is usually a nightmare of manual fixings
[14:51:33 CEST] <Yagiza> Also, I wonder, which file contains code for SDP demuxing? sdp.c or rtsp.c?
[14:52:24 CEST] <LigH> nevcairiel, it mentions a flag -DGLIB_STATIC_COMPILATION ... I will share that issue, thank you.
[14:52:45 CEST] <nevcairiel> you probably need that when building lensfun, not when building ffmpeg, fwiw
[14:54:02 CEST] <LigH> Yes. I will test that.
[14:54:09 CEST] <LigH> It looks like a CMake flag.
[14:54:28 CEST] <nevcairiel> its a compiler flag for gcc
[14:54:31 CEST] <nevcairiel> to define that macro
[14:55:25 CEST] <LigH> Hmm, then I need to discover how to patch the suite. And possibly only for the case that ffmpeg will be built statically.
[15:25:25 CEST] <BBB> do I use GRAY16 for 10-bit 4:0:0?
[15:25:29 CEST] <BBB> as AvPixelFormat
[15:26:50 CEST] <j-b> 10bit 4:0:0?
[15:26:54 CEST] <j-b> what?
[15:28:22 CEST] <BBB> all modern video codecs have it; dont ask me why
[15:28:33 CEST] <j-b> why?
[15:28:34 CEST] <j-b> :D
[15:30:48 CEST] <thardin> medical stuff?
[15:33:07 CEST] <durandal_1707> BBB: no, there is 10 bit gray
[15:43:15 CEST] <BBB> ah ok cool
[16:18:50 CEST] <LigH> There is support for chroma subsampling i400, I do remember that x265 supports Y4M with e.g. "mono10" as color space marker... but not sure what ffmpeg expects in which options.
[16:19:36 CEST] <LigH> 400p10 seems not to exist.
[16:19:48 CEST] <nevcairiel> those formats are called gray
[16:20:05 CEST] <nevcairiel> there is no chroma subsampling, chroma is just non-existant
[16:22:16 CEST] <LigH> Yes, gray10 exists.
[16:22:44 CEST] <LigH> For -pix_fmt
[16:23:54 CEST] <LigH> Bye.
[17:15:00 CEST] <atomnuker> BBB: haha, av1 doesn't
[17:15:14 CEST] <BBB> huh what?
[17:15:23 CEST] <atomnuker> you can partially thank luc and CFL for av1 lacking 4:1:1 support
[17:16:15 CEST] <BBB> Ive never heard of 4:1:1
[17:16:20 CEST] <BBB> you mean 4:4:0?
[17:17:00 CEST] <atomnuker> I thought it was 4:1:1, it was vertical subsampling without horizontal subsampling, for cheapo DVs
[17:17:30 CEST] <atomnuker> er, the opposite of 422
[17:17:45 CEST] <BBB> vp9 called that 440
[17:17:56 CEST] <BBB> and yes Im glad it was deleted, dumbest thing ever
[17:19:07 CEST] <nevcairiel> 411 and 440 are different, not many people probably know exactly how that syntax works, but with the help of the wikipedia article i can usually decipher it =p
[17:19:50 CEST] <durandal_1707> 411 have horizontal subsampling only
[17:20:14 CEST] <atomnuker> if we had cut 422 derf might have been almost happy with the codec but there's no way we could, lack of interlacing and lack of limited range rgb was the best we could do to make it seem like a codec for the future
[17:21:36 CEST] <nevcairiel> the 4 is basically constant, the first digit is the number of chroma samples in the first  row of samples, the second number is the number of chroma samples in the second row. so 411 has one sample in the first row, and one sample in the second row, ie.  1/4th horizontal, full vertical
[17:21:48 CEST] <nevcairiel> while 440  has full horizontal, and  half vertical
[17:22:12 CEST] <nevcairiel> (always refering a 4x2 grid of pixel)
[17:22:35 CEST] <durandal_1707> wrong
[17:22:37 CEST] <BBB> 422 is totally b0rk3d is you ask me
[17:22:41 CEST] <BBB> (422 in av1)
[17:23:10 CEST] <nevcairiel> whats with 422 always being special
[17:23:24 CEST] <nevcairiel> for some reason in h264 422 was also so different, while 444 then again was similar to 420
[17:23:27 CEST] <durandal_1707> for 411 see y41pdec and prosumer.c in lavc
[17:24:24 CEST] <BBB> honestly, in av1, I dont know
[17:24:41 CEST] <BBB> it appears they wanted to use consistet BLOCK_SIZE ratios for all subsamplings
[17:24:59 CEST] <BBB> and since uneven hor vs. ver subsampling means different blocksize ratios, it means some partitionings are disallowed in av1 422
[17:25:10 CEST] <BBB> the rules for it are weird, if you ask me
[17:25:52 CEST] <BBB> e.g. 1:4 is allowed in 444/420, but 1:2 *and* 1:4 are disallowed in 422 because 1:4 turns into 1:8 and 1:2 something something ??????
[17:26:13 CEST] <nevcairiel> i guess that makes some sense
[17:26:15 CEST] <BBB> either 1:2 disallowing had to do with 128x128 special rules, or with a bug in the 4x8 blocks
[17:26:26 CEST] <BBB> but its still crazy to not allow it at all, no reason for it IMO
[17:31:14 CEST] <kierank> some hardware bullshit iirc
[17:34:56 CEST] <BBB> ...
[17:35:46 CEST] <BBB> I have a feeling that many quetionable design decisions - not just in av1, but really everywhere - are often attributed to some crazy hw bullshit without anyone really understanding what was actually going on; and thats a problem
[17:36:13 CEST] <nevcairiel> well some hardware guy probably does
[17:36:17 CEST] <nevcairiel> but we're all software guys
[17:36:50 CEST] <BBB> so hw supports 422?
[17:37:47 CEST] <nevcairiel> not sure speaking in present tense about av1 hardware is going to be accurate
[17:37:50 CEST] <atomnuker> yes, some should in the future, the pro profile provides support for it
[17:38:22 CEST] <nevcairiel> pro-hardware also supports 422 h264, because thats used for broadcast streams, but of course consumer never did
[17:41:14 CEST] <atomnuker> I'm not sure if the hardware companies are to blame, they were mostly civilized
[17:41:56 CEST] <atomnuker> ...when they bothered to finally evaluate a coding tool's impact, most of the time they were a bit lazy
[18:27:47 CEST] <kurosu> atomnuker, is 422 always 10 bits? 
[18:28:09 CEST] <kurosu> conversely, can 422 be 8 bits
[18:29:31 CEST] <atomnuker> absolutely
[18:30:07 CEST] <atomnuker> though if you ask some people the only true pro 422 is 10 bits
[18:30:16 CEST] <kurosu> exactly
[18:30:23 CEST] Action: kurosu asking for a friend
[20:03:14 CEST] <BBB> for a friend :D
[20:03:49 CEST] <BBB> kurosu: all these things are planar, just like h264/hevc, so bitdepth vs. chroma subsampling are completely unrelated
[20:10:13 CEST] <atomnuker> unless someone brings v210 or bitpacked into the mix in which subsampling and depth are very related
[20:15:53 CEST] <kurosu> people like having profile mandating stuff
[20:16:14 CEST] <kurosu> profiles
[20:16:46 CEST] <kurosu> though I'm really unsure the selling point of av1 matters to the pro users
[20:16:55 CEST] <kurosu> (point or points)
[20:17:10 CEST] <kurosu> s/the/such
[20:18:13 CEST] <atomnuker> you need pro profile to decode 422 anyway which already includes support for 10 and 12 bits
[20:18:59 CEST] <atomnuker> I don't remember what levels include each though, the levels were a mess and I'm glad I've forgotten what happened
[20:20:54 CEST] <BradleyS> durandal_1707: what's your method for benchmarking prores?
[20:21:13 CEST] <BradleyS> i was going to dump to a fast disk but to mem discard would probably be better
[20:21:33 CEST] <nevcairiel> just do -f null -
[20:22:02 CEST] <BradleyS> ah, perfect
[20:31:42 CEST] <durandal_1707> reduced scpr version 3 line count by -200, still many remaining for rewrite
[20:47:48 CEST] <BradleyS> Stream #0:0(und): Video: wrapped_avframe, yuv422p10le, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default)
[20:47:48 CEST] <BradleyS> frame=18000 fps=658 q=-0.0 Lsize=N/A time=00:10:00.60 bitrate=N/A speed=21.9x
[20:47:55 CEST] <BradleyS> multithreaded from ramdisk
[20:48:29 CEST] <BradleyS> xeon w3680 on macos
[20:48:40 CEST] <durandal_1707> and now with -thread_type slice?
[20:48:41 CEST] <BradleyS> (well, vice versa)
[20:49:54 CEST] <BradleyS> i should have averaged multiple, it's more like 665
[20:49:59 CEST] <BradleyS> sliced, 669
[20:50:27 CEST] <BradleyS> that said, this is pre-haswell and 1333 mhz ddr3
[20:51:11 CEST] <BradleyS> newer arch probably performs better with frame threading, we've seen similar differences between pre-haswell and say skylake with handbrake's nlmeans denoiser and frame threads
[20:51:42 CEST] <BradleyS> it's possible i'm memory bound, basically
[20:53:51 CEST] <BradleyS> speed test shows ramdisk 2550/1300 MB/s read/write
[20:54:50 CEST] <durandal_1707> BradleyS: how much RAM?
[20:55:33 CEST] <BradleyS> 24 GB, about 10 free (i made sure to free up as much as possible)
[20:56:11 CEST] <BradleyS> going to try smaller and larger frame sizes
[20:56:23 CEST] <durandal_1707> BradleyS: -thread_type is input option
[20:57:41 CEST] <BradleyS> oof, that's probably it too, give me a moment
[21:07:28 CEST] <BradleyS> ffmpeg -thread_type slice -i /Volumes/ramdisk/720p.mov -f null -
[21:07:28 CEST] <BradleyS> Stream #0:0(und): Video: wrapped_avframe, yuv422p10le, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default)
[21:07:28 CEST] <BradleyS> frame=18000 fps=497 q=-0.0 Lsize=N/A time=00:10:00.60 bitrate=N/A speed=16.6x    
[21:07:28 CEST] <BradleyS> video:9422kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[21:08:01 CEST] <BradleyS> so that is a nice speedup after all
[21:08:13 CEST] <atomnuker> durandal_1707: btw I have some .binka files, wanna take a look at them?
[21:08:22 CEST] <BradleyS> about 33%
[21:09:06 CEST] <durandal_1707> atomnuker: looked at their decoder/encoder, probably imdct based
[21:10:20 CEST] <durandal_1707> i think i removed/lost dlls
[21:10:55 CEST] <BradleyS> 480p 1075/1224 fps
[21:11:17 CEST] <BradleyS> 720p 497/665 fps
[21:13:47 CEST] <BradleyS> will take awhile for my 1080p and 2160p to render, will report back in a bit
[21:22:08 CEST] <durandal_1707> atomnuker: i still have them. binkawin.asi and few binka samples
[21:22:26 CEST] <durandal_1707> only 54k
[21:22:44 CEST] <durandal_1707> should be straightforward to RE even for noobs
[21:30:56 CEST] <durandal_1707> actually there is one small problem
[21:31:51 CEST] <durandal_1707> ida reports call analysis failed for main function responsible for stream decompression
[21:32:25 CEST] <durandal_1707> and i haven't looked much after that
[21:33:46 CEST] <jamrial> atomnuker: ^
[21:43:39 CEST] <BradleyS> 1080p 261/339
[21:49:41 CEST] <jamrial> atomnuker: libfdk-aac also sets the correct 5.0/5.1 layouts, yet the resulting file doesn't end up with ffprobe saying channel_layout=unknown
[21:50:53 CEST] <atomnuker> they don't implement PCEs, so the decoder's probably doing something
[21:51:46 CEST] <BradleyS> 2160p 75/93 fps
[21:52:09 CEST] <BradleyS> durandal_1707: is there somewhere you would like me to post the results?
[21:54:58 CEST] <nevcairiel> if ffmpeg itself cannot recognize the layout of those PCE files, then you should consider that a bug no matter what
[21:55:04 CEST] <nevcairiel> perhaps in the decoder, but there is definitely a bug
[21:55:36 CEST] <atomnuker> I know, I'm looking into it
[21:57:42 CEST] <durandal_1707> BradleyS: on twitter?
[22:09:46 CEST] <BBB> jamrial: should I stop asking? &
[22:10:13 CEST] <durandal_1707> jamrial: just accept invitation
[22:10:21 CEST] <BradleyS> durandal_1707: whether you were serious or not, here it is https://twitter.com/bradleysepos/status/1034533519530315776
[22:10:22 CEST] <BradleyS> thanks
[22:10:42 CEST] <jamrial> BBB: yes, it would help a lot in making up my mind if i'm not badgered about it all the time
[22:11:18 CEST] Action: BBB will shut up
[22:11:38 CEST] <nevcairiel> Big Bad Badger?
[22:11:40 CEST] <nevcairiel> it all makes sense
[22:15:07 CEST] <durandal_1707> for me BBB always stand for Big Buck Bunny
[22:15:30 CEST] <nevcairiel> absolutely, but he insists he came before
[22:16:35 CEST] <jamrial> i met him before i ever watched that short, so the other way around for me
[22:26:58 CEST] <atomnuker> for me BBB means Bromley-By-Bow
[22:27:50 CEST] <BradleyS> https://www.google.com/search?q=htda+bbb
[22:27:52 CEST] <atomnuker> which is 2 stops away from Mile End where you can transfer for the central line to evade the constant delays on the District/H&C line just before Aldgate
[22:28:54 CEST] <durandal_1707> atomnuker: you just wrote what?
[22:31:20 CEST] <atomnuker> yes, each ride on the underground is traumatic enough to remember if you go to heathrow
[22:32:09 CEST] <atomnuker> "I can cheat the system and go to the central line, and take the picadilly line or the heathrow express!" goes through the minds of most travellers crossing the city from the east to heathrow
[22:33:28 CEST] <atomnuker> but no, turns out time wise its actually better to suffer going through all the stops on the district line (20ish) and transfer for the picadilly line on gloucester road
[22:36:38 CEST] <atomnuker> the elizabeth line might speed things up a lot and maybe even make the hyperexpensive heathrow express redundant but that opens in december, according to schedule
[22:39:51 CEST] <atomnuker> I should be in madrid by then if things go well enough, ~15 minutes on the tube from the center to the airport, it takes me 2h 30m here
[22:40:42 CEST] Action: BradleyS wishes he had rapid underground/rail transport
[22:41:48 CEST] <BradleyS> this is as far as my state has gone with it https://en.wikipedia.org/wiki/Ohio_Hub
[22:41:55 CEST] <BradleyS> no current funding, all but dead
[22:42:23 CEST] <BradleyS> the longer we wait the more crowded roads become, it's literally 3-4x worse than it was 10 years ago where i live now
[22:44:03 CEST] <BradleyS> with distracted driving (texting) it's pretty nightmarish, narrowly avoid accidents every single drive
[22:45:13 CEST] <robUx4> michaelni: can you hear us in the meeting ?
[22:47:25 CEST] <durandal_1707> ?
[22:54:05 CEST] <atomnuker> turns out that our aac decoder instantly gives up if AAC_CHANNEL_SIDE is present in the layout map parsed from PCEs
[22:54:27 CEST] <atomnuker> peloverde: do you have the time to look at it?
[23:02:43 CEST] <peloverde> I'm too busy right now, sorry. 
[23:03:16 CEST] <atomnuker> k, I think we're signalling PCEs badly too
[00:00:00 CEST] --- Wed Aug 29 2018