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

[burek]

[00:00:13 CEST] <durandal_1707> peloverde: i dont with my code,  fdkdecoder chokes
[00:02:58 CEST] <peloverde> I'm not following
[00:06:09 CEST] <peloverde> I'm literally seeing 0 error compared to the reference with ftp://mpaudconf:adif2mp4@ftp.iis.fhg.de/mpeg4audio-conformance/compressedMp4/al01sf_48.mp4
[00:06:24 CEST] <peloverde> (I had forgotten about the sf suffixed files, they are 960)
[00:06:59 CEST] <peloverde> And it's abundantly clear that decode_spectrum_and_dequant() isn't handling 120 length windows properly
[00:14:56 CEST] <kierank> J_Darnley: will publish it properly tomorrow
[00:15:42 CEST] <J_Darnley> Hey, mirc flashed this time.  Also: ACK
[03:28:58 CEST] <cone-432> ffmpeg 03Derek Buitenhuis 07master:fde9013ab424: mpegtsenc: Don't pass NULL to memcpy
[03:49:35 CEST] <cone-432> ffmpeg 03Rafaël Carré 07master:3b9cf943c97f: h264dec: remove unneeded prototype
[03:49:36 CEST] <cone-432> ffmpeg 03Wan-Teh Chang 07master:dc11a467e622: ffmpeg: Fix typos in the comment for decode() ("." vs. "->")
[04:06:18 CEST] <cone-432> ffmpeg 03Steven Liu 07master:23e21130bbbe: avformat/hlsenc: add warn message when use both fmp4 and single_file
[04:09:54 CEST] <cone-432> ffmpeg 03Derek Buitenhuis 07master:2d417076a2a7: avformat/hlsenc: Add missing error check
[04:42:41 CEST] <cone-432> ffmpeg 03Muhammad Faiz 07master:1af615683e4a: avcodec/fft_template: use ff_thread_once on costable initialization
[09:47:33 CEST] <durandal_1707> peloverde: so whats missing in that spectrum function?
[10:02:14 CEST] <jya> when decoding a profile 2 vp9 (10 bits YCbCr), ffmpeg colorspace gives me AVCOL_SPC_UNSPECIFIED, can I safely assume it to be Rec 2020 ?
[10:03:33 CEST] <nevcairiel> there is no way to know what was used for encoding
[10:03:44 CEST] <nevcairiel> unless someone put it into the bitstream
[10:04:43 CEST] <jya> nevcairiel: i guess hence the "safely" bit :)
[10:05:03 CEST] <jya> likely better than thinking it's BT709
[10:05:22 CEST] <nevcairiel> youtube vp9 encodes put such info in the container, might want to snoop there for info
[10:06:46 CEST] <jya> right... let me see what I got from that youtube video I downloaded
[10:07:46 CEST] <nevcairiel> Obviously you need to guess some colorspace, and while i've seen 10-bit 709 encodes quite a bit as well, maybe not specifically in vp9
[10:08:14 CEST] <wm4> unless there's a container or bitstream flag that something doesn't read, you can't know
[10:11:12 CEST] <jya> yep, AVCOL_SPC_BT2020_NCL
[10:11:37 CEST] <jya> that's reading youtube
[10:12:42 CEST] Action: jya wondering what's the difference between AVCOL_SPC_BT2020_NCL and AVCOL_SPC_BT2020_CL
[10:13:05 CEST] <JEEB> non-constant luminance and constant luminance
[10:13:29 CEST] <JEEB> someone like hanna can tell about how CL is objectively better but everyone seems to use NCL
[10:18:31 CEST] <hanna> yeah we should be using CL
[10:18:40 CEST] <hanna> because the only reason not to is uh.... it's slightly more difficult to implement!
[10:18:56 CEST] <hanna> you have to actually change the algorithm instead of just slapping new matrix constants onto existing code!
[10:19:03 CEST] <nevcairiel> NCL is basically how shit worked for years, people are slow to change =p
[10:19:13 CEST] <hanna> does that statement include anime people
[10:19:17 CEST] <hanna> why aren't anime releases CL yet
[10:19:24 CEST] <hanna> especially anime would benefit from this
[10:19:30 CEST] <nevcairiel> anime people just jump on hype tech, not on smart tech
[10:19:34 CEST] <hanna> because it *significantly* reduces color ringing due to subsampling
[10:19:36 CEST] <hanna> around lines
[10:19:43 CEST] <hanna> well then we know what the problem is
[10:19:47 CEST] <hanna> somebody needs to hype CL
[10:19:56 CEST] <hanna> make comparison screenshots, spam on /a/ and /g/
[10:20:09 CEST] <nevcairiel> also it would probably reduce playback support significantly
[10:20:27 CEST] <hanna> although that being said, CL is standardized in all of the relevant standards I know
[10:20:40 CEST] <hanna> so it's not like this is some hack non-standard modification
[10:20:53 CEST] <hanna> CL is also a thing for HDR :D
[10:21:12 CEST] <hanna> if you're going to bother implementing HDR you might as well bother implementing CL, no?
[10:21:45 CEST] <hanna> (for HDR, it's called ICtCp)
[10:21:53 CEST] <hanna> (and no, mpv doesn't support it yet :()
[10:21:57 CEST] <hanna> (test clips welcome)
[10:23:30 CEST] <nevcairiel> apparently CL loses details in the green parts of a RGB image, oddly enough
[10:24:13 CEST] <nevcairiel> ITU-R BT.2246-6 has some  fancy comparisons between CL and NCL
[10:26:48 CEST] <hanna> oh yeah, that report is pretty damn good
[10:26:59 CEST] <hanna> I lost track of the number of times I've quoted from it
[10:28:06 CEST] <JEEB> nevcairiel, hanna - anime people didn't get to using CL because the input is BT.709/BT.709/BT.709
[10:28:19 CEST] <hanna> here are some of my really really old screenshots
[10:28:23 CEST] <nevcairiel> guess so, noone makes native bt2020 content for anime
[10:28:29 CEST] <hanna> JEEB: you can transcode between CL and NCL
[10:28:32 CEST] <hanna> it's just a different representation
[10:28:39 CEST] <hanna> oh I see what you mean
[10:28:42 CEST] <nevcairiel> its not defined for 709 tho
[10:28:46 CEST] <hanna> you mean applying CL to BT.709 is non-standard
[10:29:04 CEST] <hanna> ncl.png https://0x0.st/0nM.png
[10:29:05 CEST] <nevcairiel> you could put 709 into a 2020 container, but you would probably waste more "space" then you would gain
[10:29:06 CEST] <hanna> cl.png https://0x0.st/0nB.png
[10:29:08 CEST] <JEEB> other than UHD BD, nevcairiel - but those aren't exactly massively ripped (there's some anime in that format but it's all lol upscales)
[10:29:24 CEST] <hanna> both are 4:2:0 subsampled
[10:29:54 CEST] <hanna> but the boundary between green and red is much smoother for cl because it has the same luminosity
[10:29:58 CEST] <hanna> just the color shifts
[10:30:14 CEST] <hanna> whereas the mixing of red and green in non-constant luminance, as usual, darkens the result
[10:30:43 CEST] <hanna> JEEB: 4K HDR wide-gamut anime when?
[10:30:46 CEST] <hanna> seriously anime wide gamut would be amazing
[10:30:55 CEST] <hanna> imagine something like katanagatari in wide gamut
[10:31:25 CEST] <hanna> watching the katanagatari OP stretched to wide gamut is pretty damn impressive, although the skin tones are all off which is why you can't do it in practice
[10:34:08 CEST] <JEEB> hanna: well if we get any of the UHD BD animoo ripped we will get a "properly mastered" wide gamut sample of it
[10:36:08 CEST] <hanna> so they're out, just not cracked?
[10:36:10 CEST] <hanna> or what
[10:36:25 CEST] <hanna> anyway I expect anime studios to trail behind like 30 years here
[10:36:43 CEST] <hanna> because producing wide gamut / 4K / HDR anime would mean investing in wide gamut / 4K / HDR equipment
[10:44:32 CEST] <JEEB> yea, they're out but not actually available as source material
[11:51:17 CEST] <nevcairiel> heh its always amusing when ISO/IEC tries to sell you a standards document, and the same standard was also published by the ITU under their own name for free
[11:52:31 CEST] <nevcairiel> (in case anyone wonders, ISO/IEC 23001-8:2016 is available as ITU-T H.273)
[11:54:33 CEST] <JEEB> funky
[11:54:53 CEST] <JEEB> also I remember the time in 2012 when ITU-T had H.222 available for free for a while :P
[11:55:01 CEST] <JEEB> that seemed to be a mistake though
[11:55:15 CEST] <nevcairiel> i must've grabbed it at such a time, because i have one
[12:01:41 CEST] <kierank> i have it aswell
[12:03:54 CEST] <cone-863> ffmpeg 03DongHoon Kang 07master:db8f615d6866: libavcodec/htmlsubtitles.c: make tags case-insensitive
[12:31:33 CEST] <J_Darnley> atomnuker: can I bug you with more questions about vc2/dirac?
[12:32:36 CEST] <atomnuker> J_Darnley: don't ask to ask, just ask
[12:32:50 CEST] <J_Darnley> Well, it was more "are you here"
[12:35:01 CEST] <J_Darnley> How should the coeffs be arranged for the idwt?  Should all the lowest be together?  Should higher ones be interleaved in some fashion?
[12:35:25 CEST] <atomnuker> up to you
[12:35:35 CEST] <J_Darnley> What?
[12:36:03 CEST] <J_Darnley> What does that mean?  How can I do a transform if the coeffs are all wrong?
[12:36:08 CEST] <atomnuker> the traditional way is to have them as 4 rectangles adding up to the size of the original image
[12:36:58 CEST] <atomnuker> what I mean is that transform order or the way a transform is done is not important, you can do it any way you'd like
[12:37:45 CEST] <atomnuker> but obviously you'd like to not have to permute the coefficients after you receive them
[12:38:38 CEST] <atomnuker> vc2 sends coefficients in the traditional way, so you end up with rectangles of coefficients adding up to the size of a single slice
[12:39:11 CEST] <J_Darnley> So all the lowest ones come together first in the bitstream?
[12:39:19 CEST] <atomnuker> yes
[12:40:29 CEST] <atomnuker> you receive an LL and you use the LH, HL, HH to upscale it to the second level from the bottom up
[12:41:10 CEST] <atomnuker> then your new upscaled LL becomes the LL to use in your second level transform using LH2, HL2, HH2
[12:41:56 CEST] <atomnuker> (that's why you're not send an LL after the bottom level)
[12:42:16 CEST] <atomnuker> this is exactly how the forward transforms work but in reverse
[12:42:41 CEST] <atomnuker> I think the decoder uses an odd scheme where it interleaves the coefficients for some reason
[12:42:52 CEST] <J_Darnley> It appears to, yes
[12:43:13 CEST] <J_Darnley> The stride for the lowest level is 4 times the stride of the plane
[12:44:23 CEST] <atomnuker> told ya, the encoder would've been easier
[12:44:44 CEST] <J_Darnley> But kierank says the encoder already works, or something
[12:44:54 CEST] <kierank> atomnuker: why is the encoder easier?
[12:45:18 CEST] <J_Darnley> Okay, moving past my ignorance of how that transform works.  I think understand the bitstream order...
[12:45:30 CEST] <atomnuker> because the transforms are usable as-is on a per slice basis without having to write new ones
[12:45:38 CEST] <atomnuker> and you know how difficult it is to write new ones
[12:46:07 CEST] <iive> is this about snow?
[12:46:15 CEST] <kierank> oh i see
[12:46:18 CEST] <kierank> ok J_Darnley do what atomnuker says
[12:46:21 CEST] <J_Darnley> iive : no vc2/dirac
[12:46:58 CEST] <iive> during inital snow development i do remember that somebody did a change, making it work on a slice at a time
[12:47:27 CEST] Action: J_Darnley WTFs
[12:47:29 CEST] <iive> and it did also brought quite nice speed improvement, because it was more cache efficent.
[12:47:50 CEST] <iive> they are all wavelets ?
[12:48:27 CEST] <J_Darnley> Fuck you wavelets!
[12:49:23 CEST] <atomnuker> iive: that's what I saw when I modified the vc2 encoder to do that
[12:49:28 CEST] <atomnuker> it was a huge increase indeed
[12:53:24 CEST] <J_Darnley> atomnuker, kierank: just so I am clear...  I am supposed to modify the encoder so it does a per-slice transform rather than a whole plane transform?
[12:53:32 CEST] <kierank> yes
[12:56:52 CEST] <kierank> http://obe.tv/about-us/obe-blog/item/46-optimising-and-modernising-ffmpegs-idct-part-2
[13:08:07 CEST] <wm4> " Using git-blame to identify the last time a line was changed you can use git-show to show that patch and the message. If that wasn't related then use git-blame again on the preceding commit to see the time it was changed before then.  Keep going until you discover the origin."
[13:08:20 CEST] <wm4> if you use gitk it's usually just a few clicks
[13:08:54 CEST] <kierank> wm4: remember you are more of a neckbeard if you do stuff a hundred times more complicated on the CLI
[13:09:02 CEST] <kierank> instead of two clicks in a gui
[13:09:10 CEST] <kierank> there's stuff I do in sourcetree that takes 5 commands
[13:14:55 CEST] <wm4> gitk is written in tcl/tk and looks fugly, so it should be neckbeard compatible
[13:17:55 CEST] <J_Darnley> I'd rather use tig but I don't know it well enough yet.  Plus it can never hurt to know how to use the base tools
[13:28:09 CEST] <iive> wm4: gui requires using graphic environment, xorg, wayland, mir. No video develop uses such a thing. That's also why source code and commit messages should be limited to a single text  screen.
[13:28:51 CEST] <iive>  /s
[13:28:52 CEST] <wm4> all of that is false
[13:33:46 CEST] <iive> well, gui does require graphics
[13:34:44 CEST] <iive> gui also change their interface from time to time. CLI is usually kept consistent for much longer.
[13:36:18 CEST] <nevcairiel> should totally build a ncurses git gui just to show you!
[13:36:58 CEST] <iive> nevcairiel: git <command> -i :P
[13:37:28 CEST] <iive> also, does the gui tcl/tk parts get used under windows?
[13:40:42 CEST] <JEEB> they can be used, although I've only ever used them under cygwin myself
[13:40:54 CEST] <JEEB> I wouldn't be surprised if you could build them for native windows as well
[13:42:08 CEST] <iive> but are they? becuse the gui part can easlity become a magnitude bigger than the git itself.
[13:56:21 CEST] <hanna> re: test files for HDR crap, what would be the best way to dump out a single frame of a file into a new .mkv while preserving the metadata?
[13:56:34 CEST] <hanna> Might try making some ICtCp files as well
[14:53:36 CEST] <durandal_1707> kierank: if care for speed let work on bitstream reader?
[14:56:02 CEST] <atomnuker> (not speed, latency)
[15:05:05 CEST] <kierank> durandal_1707: not worried about speed, i care about sub-frame latency
[15:05:59 CEST] <durandal_1707> thats very dissapointing
[15:07:57 CEST] <kierank> durandal_1707: i am not getting involved in bitstream reader drama
[15:08:16 CEST] <durandal_1707> im very very sad
[15:13:12 CEST] <kierank> durandal_1707: Sad!
[15:13:44 CEST] <durandal_1707> usa
[15:14:47 CEST] <BBB> lol
[15:15:11 CEST] <BBB> J_Darnley: where is blog?
[15:15:55 CEST] <J_Darnley> http://obe.tv/about-us/obe-blog/item/46-optimising-and-modernising-ffmpegs-idct-part-2
[15:18:37 CEST] <BBB> unfortunate effect of legacy code: you dont always remember why :D
[15:18:39 CEST] <BBB> indeed
[15:19:19 CEST] <durandal_1707> so whats left to do?
[15:19:20 CEST] <BBB> one of the nice thing about blogs is that we can write about it so its preserved forever
[15:19:29 CEST] Action: funman looks for help with PAFF
[15:19:32 CEST] <BBB> durandal_1707: it was pushed a few weeks ago, so in practice nothing
[15:19:42 CEST] <funman> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_slice.c;h=6deb08fe6d064b5d98a753817916f3589b5c2d54;hb=HEAD#l1567 is that comparison right?
[15:20:09 CEST] <funman> looking at http://streams.videolan.org/samples/V-codecs/h264/422/h264_422.ts I can see that frame_num does not increment every frame (or every 2 fields)
[15:22:11 CEST] <funman> e.g. looking at 75 coded fields, I only see 14 different values of frame_num
[15:22:59 CEST] <funman> reading h264 7.4.3 Slice header semantics frame_num seems more complex than the name suggests
[15:25:34 CEST] Action: funman notices https://github.com/FFmpeg/FFmpeg/commit/12d96de3acf660d53d6931e2045ec21fd8ae718f#diff-e71870cf1b945f212b3c9380f59c273cR4016 mentions reference pictures
[15:35:29 CEST] <kierank> 2:19 PM <funman> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_slice.c;h=6deb08fe6d064b5d98a753817916f3589b5c2d54;hb=HEAD#l1567 is that comparison right?
[15:35:32 CEST] <kierank> that's a heuristic i think
[16:05:28 CEST] <J_Darnley> WTF is this crap?  How is that function pointer 0?
[16:06:17 CEST] <atomnuker> durandal_1707: dirac doesn't really use any part of the bitstream reader to read coefficients
[16:06:27 CEST] <atomnuker> look at libavcodec/dirac_vlc.c
[16:06:54 CEST] <atomnuker> it used to, but it was not fast and was never going to be as fast as this lookup table based one
[16:07:14 CEST] <atomnuker> I tried to use the vlc reader we had but couldn't figure out how to generate tables
[16:07:44 CEST] <atomnuker> (even though the golomb codes are similar to the codes used in h264, they're quite different)
[16:08:31 CEST] <atomnuker> and I think it would have been slower still if I had used that one
[16:09:02 CEST] <atomnuker> since alot of the coefficients turn to 0 and you'd still need to run the entire decoding process on them
[16:09:15 CEST] <iive> atomnuker: remind me to look up the vlc code generation, after pvq_search is committed.
[16:09:56 CEST] <atomnuker> the dirac_vlc reader knows however and can SFMD multiple coefficients together
[16:10:00 CEST] <iive> atomnuker: btw, they are static, right? no statistic/probability updates on them.
[16:10:03 CEST] <atomnuker> (single function multiple data)
[16:10:06 CEST] <atomnuker> they're static
[16:19:53 CEST] <mateo`> jamrial: Hello, I've looked at checkasm on arm, I did not get any failure on two armv7 boxes, and the asm code that calls the tested functions does not override the returned value
[16:20:47 CEST] <jamrial> mateo`: ok, cool
[16:20:57 CEST] <jamrial> wonder why that one arm fate box reported a failure on checkasm-float_dsp, then
[16:21:00 CEST] <jamrial> thanks for looking
[16:22:56 CEST] <mateo`> jamrial: this one http://fate.ffmpeg.org/report.cgi?time=20170704083953&slot=armv7l-panda-gcc4.4-cortexa8 ?
[16:23:23 CEST] <jamrial> yeah
[16:43:07 CEST] <mateo`> jamrial: well, I don't why those tests fail on this box, maybe the memory poisoning option has to do with it, i'll take some time to investigate later on
[16:44:36 CEST] <iive> btw, what does checkasm test for? what does it run as reference? a non poisoned asm function?
[16:50:08 CEST] <mateo`> iive: it runs both the C and ASM functions of a dsp and compares its output
[16:50:19 CEST] <mateo`> the input in generated with random
[16:52:03 CEST] <iive> i can't spot the place where it gets the pointer to the C function.
[16:53:30 CEST] <ubitux> the dsp points on the c function if you init with the 0 cpuflags
[16:56:13 CEST] <iive> that's the thing that confuses me. I see only one initialization of dsp context, in the function, outside of any macro.
[17:06:39 CEST] <Gramner> iive: it's basically lots of evil preprocessor macro stuff behind the scenes going on
[17:07:27 CEST] <iive> maybe it runs the first test with cpuflags=0 and same ref and new functions ?
[17:07:33 CEST] <Gramner> it calls another function to do a lookup in a binary search tree for a pointer to the reference function
[17:07:59 CEST] <Gramner> it's called with cpuflags=0 first
[17:08:06 CEST] <Gramner> and saves that function pointer for later
[17:08:55 CEST] <Gramner> see checkasm.c and checkasm.h
[17:14:56 CEST] <iive> another lame question. can I run checkasm without running the whole fate?
[17:15:27 CEST] <ubitux> yes
[17:15:34 CEST] <ubitux> make checkasm && ./tests/checkasm/checkasm
[17:15:40 CEST] <ubitux> or make fate-checkasm
[17:15:52 CEST] <iive> thanks
[17:16:19 CEST] <Gramner> optional --bench=<prefix> parameter for benchmarking stuff
[17:16:41 CEST] <iive> oh, i have to do it from the root of ffmpeg source, not from tests/
[17:17:43 CEST] <ubitux> s/source/build dir/ (which can be the source tree)
[17:20:24 CEST] <iive> do we support now building outside the source tree?
[17:20:36 CEST] <nevcairiel> always have
[17:21:13 CEST] <nevcairiel> the default fate script in the tests directory even does that, so most fate boxes prboably do
[17:21:36 CEST] <iive> i remember somebody trying to implement it and doing it wrong...
[17:27:19 CEST] <ubitux> aren't you remembering the reproducible state thing with the src link?
[17:27:38 CEST] <nevcairiel> ah yeah the dumb debian hacks that never worked
[17:35:16 CEST] <thardin> reading the itu jpeg spec. seems jpeg is a lot more sophisticated than i thought
[17:36:04 CEST] <thardin> hierarchical encoding especially
[17:36:36 CEST] <thardin> almost waveletish
[17:45:08 CEST] <J_Darnley> Woo! random noise output!
[17:45:30 CEST] <J_Darnley> except for the last 3(?) slices, lol
[17:47:32 CEST] Action: J_Darnley is afk for dinner
[17:47:36 CEST] <peloverde> durandal_1707: during unpacking your coef window stride is 128 but when reading them in the transform it's 120
[17:48:10 CEST] <peloverde> Looking at it further, I think changing it in the itx-windowing is probably easier
[17:48:30 CEST] <peloverde> There are a ton of 128 short window strides littered through out the codebase
[17:57:12 CEST] <durandal_1707> atomnuker: utvideo decoding speed: libav 117fps, my bitreader 178fps
[17:58:22 CEST] <cone-885> ffmpeg 03Tobias Rapp 07master:8bf9572e9a54: avformat: remove obsolete commented-out DEBUG define
[18:03:20 CEST] <atomnuker> durandal_1707: wow, nice
[18:44:26 CEST] <peloverde> durandal_1707: Did you amend or change the commit recently I have 1c04fa5daced305ba820f5f64e39ab8451e73bdd exploding and 38e8d39e084d9b909a23d0a72426e32d5335c7a5 decoding with artifacts
[18:47:12 CEST] <peloverde> Ahh looks like you added the 120 swb tabs, I thought I remembered those being missing
[18:49:00 CEST] <durandal_1707> peloverde: and sbr something
[18:49:17 CEST] <durandal_1707> but i always get artifacts
[19:08:03 CEST] <peloverde> So I think I've fixed the artifacts, but mdct_error.flv has a bitstream desync that wasn't there before
[19:15:00 CEST] <peloverde> The bitstream desync is before my changes
[19:30:22 CEST] <durandal_1707> peloverde: have patch?
[19:33:07 CEST] <peloverde> durandal_1707: https://pastebin.com/drs9Lk9k
[19:33:26 CEST] <peloverde> The top part I'm suspicious of, the bottom part I'm confident about
[19:39:15 CEST] <peloverde> I'd like to find a reference sample that goes all the way to max_sfb on short windows
[19:40:11 CEST] <peloverde> err max_sfb goes all the way to num_swb
[19:56:49 CEST] <durandal_1707> peloverde: i still get artefacts with isobmff sample
[19:59:08 CEST] <peloverde> durandal_1707: That's HE-AAC, lots of additional changes will be necessary
[19:59:21 CEST] <peloverde> filterbank is a good place to start
[19:59:46 CEST] <peloverde> but AAC-LC 960 is a farily cohesive unit and can probably move forward without HE-AAC
[20:00:00 CEST] <durandal_1707> what needs change?
[20:01:36 CEST] <peloverde> The filterbank needs to support 960 input and 960 and 1920 output
[20:03:40 CEST] <peloverde> And the filterbank is implemented on top of the mdct so it will probably get ugly
[20:04:28 CEST] <peloverde> It's probably best to move forward with LC first and just disable SBR with short frame length flags
[20:11:50 CEST] <peloverde> If you turn off SBR you should trade the artifacts you are getting for a loss of high frequencies
[20:52:03 CEST] <BBB> uhm
[20:52:04 CEST] <BBB>  s->cache       = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) << s->cache | s->cache;
[20:52:06 CEST] <BBB> ???
[20:52:22 CEST] <BBB> I assume that middle s->cache should be s->bits_left?
[20:53:06 CEST] <BBB> durandal_1707: ^^
[20:55:52 CEST] <durandal_1707> fixed
[20:55:58 CEST] <atomnuker> durandal_1707: I think it should be enabled by default and disabled on demand
[20:57:06 CEST] <durandal_1707> atomnuker: i think other way arround
[20:57:15 CEST] <jamrial> atomnuker: that depends on how many codecs see gains with this. if most do, then sure. but if most don't, then it should be enabled on demand.
[20:58:56 CEST] <BBB> can cache be 32bits on 32bit (HAVE_FAST_64BIT=0) systems?
[20:59:12 CEST] <BBB> (s/can/should/ maybe)
[21:00:09 CEST] <atomnuker> that'd be fine too
[21:04:26 CEST] <iive> if you are going to have a cache, then you can at least do an aligned reads. this way byteread macros won't need to do its own double read and shuffles.
[21:12:28 CEST] <durandal_1707> iive: what you mean exactly.?
[21:15:14 CEST] <peloverde> durandal_1707: So the only ref that uses all SWBs is the PNS ref where there are no coef reads anyway :(
[21:24:44 CEST] <iive> durandal_1707: since the code use index>>3 I do assume that's byte granularity. So on architecture (like arm) that does not allow unaligned access, the macro would either do 4 byte reads or 2 dwords and then shift them 8,16,24 bits.
[21:33:05 CEST] <nevcairiel> if that is the case we can always put it under HAVE_FAST_UNALIGNED or whatever
[21:33:54 CEST] <iive> well, a number of intel cpu have severe penalty if doing a read that crosses cache lines, that's 64 bytes.
[21:34:30 CEST] <nevcairiel> anyway AV_RL32 etc are designed to work on unaligned data
[21:34:35 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:b603ef0870f3: bitpacked: Remove dead store
[21:34:35 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:704b774ae029: af_tempo: Add missing error check
[21:34:36 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:f7daed854532: scpr: Added missing error check
[21:34:37 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:179bf86fa2f5: opusdec: Remove dead code
[21:34:38 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:d74ba68acf30: ffmpeg_opt: Make get_timecode actually return errors
[21:34:39 CEST] <nevcairiel> we specifically have AV_RL32A for things we know are aligned
[21:34:40 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:aa2bc61a3e32: cngenc: Remove dead store
[21:34:40 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:c27d7c027cd7: rtmpproto: Fix error return
[21:34:41 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:b198e0913854: af_amix: Add missing error check
[21:34:42 CEST] <cone-885> ffmpeg 03Derek Buitenhuis 07master:51db26231255: bitstream_filter: Add missing error check
[21:34:43 CEST] <tdjones> I'm having a problem where switching to a short window in the vorbs encoder requires a shorter residue partition length than long windows. Even with identical codebooks to libvorbis, terrible noise is introduced whenever a short window is being encoded. https://0x0.st/07P.jpg
[21:35:08 CEST] <nevcairiel> (actually, AV_RN32A since it only supports native endianness)
[21:35:25 CEST] <iive> nevcairiel: my point is, that once the buffer is aligned, we can keep it aligned by doing only 32bit reads.
[21:35:48 CEST] <tdjones> It must either be a problem  with encoding the partition codeword for each channel or encoding the residual values inside each partition
[21:36:00 CEST] <nevcairiel> sounds like unnecessary optimizations to me, it seems plenty fast without such complexity
[21:36:09 CEST] <tdjones> Anybody have any suggestions on how to debug this?
[21:36:22 CEST] <atomnuker> tdjones: might be bitstream desyncs
[21:36:44 CEST] <iive> nevcairiel: it's actually a simplification.
[21:37:09 CEST] <atomnuker> tdjones: encode a single frame using -aframes 1 and put printfs on the first value read on the encoder and decoder
[21:37:19 CEST] <nevcairiel> you dont even know if the buffer it  is given is aligned in the first place, so you need checks, and checks add cost
[21:37:29 CEST] <atomnuker> tdjones: or if you want to just printf and abort in the decoder
[21:38:02 CEST] <atomnuker> first see if the last value you read in the decoder is the same as the value you put on the encoder side
[21:38:23 CEST] <atomnuker> then I'd suggest moving from top (e.g. start of bitstream) down to the bottom
[21:42:51 CEST] <iive> nevcairiel: it doesn't have to be aligned, you can align it at init, and load the partial start in the cache.
[21:49:35 CEST] <tdjones> atomnuker: Are you saying the values after the residue and floor have been decoded? Or the encoded input for the decoder?
[21:50:39 CEST] <tdjones> The audio sounds correct if a large residue is encoded for short frames, but it raises an error in the decoder because it believes that the residue will be too large for the output buffer
[21:53:39 CEST] <atomnuker> tdjones: that doesn't matter, what I'm saying is that the encoder writes or doesn't write something it should
[21:53:52 CEST] <atomnuker> and since the decoder doesn't know it gets out of sync and starts reading wrong values
[21:54:50 CEST] <atomnuker> so you need to put a printf on values you encode and values you decode in the decoder until you find a mismatch
[21:55:04 CEST] <atomnuker> and then you'll know what's either missing or what's added that shouldn't be there
[22:16:30 CEST] <kierank> durandal_1707: do you know name of filter that shows frame side data
[22:17:24 CEST] <durandal_1707> sidedata?
[22:18:23 CEST] <kierank> yes
[22:18:29 CEST] <kierank> there was a filter iirc or a way of printing
[22:19:08 CEST] <durandal_1707> sidedata filter
[22:20:24 CEST] <kierank> ah
[22:20:25 CEST] <kierank> thanks
[22:25:50 CEST] <durandal_1707> but it just not print at all only select or delete
[22:32:01 CEST] <kierank> I add my own printf
[22:33:34 CEST] <durandal_1707> what sidedata you want?
[22:33:45 CEST] <kierank> i want to understand why field h264 loses side data
[22:33:55 CEST] <kierank> and how to merge it
[22:40:58 CEST] <ubitux> if someone has some benchmark script/samples i can try to run the bs reader in the two modes on different hardware
[22:41:15 CEST] <ubitux> i mean on a few arm32 & 64
[23:04:30 CEST] <kierank> funman: 
[23:04:31 CEST] <kierank> -        if (!h->first_field)
[23:04:31 CEST] <kierank> +        if (!h->first_field) {
[23:04:31 CEST] <kierank>              h->cur_pic_ptr = NULL;
[23:04:31 CEST] <kierank> -        ff_h264_reset_sei(h);
[23:04:31 CEST] <kierank> +            ff_h264_reset_sei(h);
[23:04:32 CEST] <kierank> +        }
[23:04:35 CEST] <kierank> was there a reason this didn't work
[23:09:24 CEST] <BBB> ah, the google guy followed through on my suggestion, nice
[23:09:28 CEST] <BBB> I believe his patch is correct this time
[23:10:00 CEST] <BBB> ubitux: should fix the spurious tsan warnings
[23:10:08 CEST] <BBB> ubitux: so only mpeg4 left for frame threading
[23:11:03 CEST] <BBB> ubitux: the debug symbols for the tsan/slice station are broken btw
[23:11:34 CEST] <ubitux> BBB: nice about the patch
[23:11:45 CEST] <ubitux> BBB: ah, that's not good news, let me check if i messed up something
[23:11:54 CEST] <BBB> configure flags look fine tbh
[23:11:58 CEST] <BBB> no idea
[23:12:21 CEST] <BBB> oh tsan/frame-mt is also broken
[23:12:23 CEST] <BBB> did you update tsan?
[23:14:07 CEST] <ubitux> it's distributed by gcc, which has been updated yes
[23:14:44 CEST] <BBB> I thought tsan was clang?
[23:14:48 CEST] <BBB> is it in gcc now?
[23:15:12 CEST] <nicolas17> I think they share that code
[23:15:21 CEST] <ubitux> both use libtsan
[23:15:26 CEST] <BBB> aha
[23:15:27 CEST] <BBB> ok
[23:15:29 CEST] <BBB> tnx for explaining
[23:15:30 CEST] <BBB> brb
[23:15:40 CEST] <nevcairiel> tsan was developed by google, both gcc and clang use it
[23:17:04 CEST] <ubitux> seems it broke with the nasm/yasm switch
[23:17:10 CEST] <ubitux> unless i'm missing something
[23:17:20 CEST] <nevcairiel> nasm seems generally to cause a bunch of issues
[23:17:30 CEST] <nevcairiel> its unfortunately not quite as flawless of a replacement as people made it out to be
[23:17:38 CEST] <ubitux> according to the fate history it broke between 664ac7c5e2 and 5cae5a1def
[23:18:22 CEST] <ubitux> btw, nasm broke object dependencies too
[23:18:43 CEST] <ubitux> i'm going to trash the .ccache though just in case
[23:19:01 CEST] <nevcairiel> the ironic thing is, it even was one of the quoted enhancements for nasm to generate the deps without a second invocation =p
[23:19:48 CEST] <jamrial> yeah
[23:20:00 CEST] <jamrial> should probably be reported to nasm
[23:20:12 CEST] <ubitux> we may be misusing it too
[23:20:24 CEST] <nevcairiel> i was meaning to figure out which asm file causes msvc to break
[23:20:32 CEST] <jamrial> http://www.nasm.us/doc/nasmdoc2.html#section-2.1.7
[23:20:35 CEST] <nevcairiel> so the nasm guys can fix their shit
[23:21:04 CEST] <jamrial> ubitux: -MD is correct, supposedly
[23:21:14 CEST] <jamrial> it's just not really getting all the dependenceis
[23:21:19 CEST] <nevcairiel> it generates some information, its just not complete, doesnt it
[23:22:15 CEST] <jamrial> it allowed me to do some testing changes on x86util without having to reassemble every .asm file, though :p
[23:22:20 CEST] <jamrial> but yeah, ideally, it should work as intended
[23:23:26 CEST] <iive> btw, I have a feeling that (separate) asm dependency generation has been removed, and that it might be needed when yasm is used.
[23:23:29 CEST] <jamrial> nasm seems to error where yasm instead warns
[23:23:30 CEST] <iive> am I wrong?
[23:23:50 CEST] <nevcairiel> it should still be there if you use yasm
[23:23:53 CEST] <jamrial> yes, you're wrong. yasm is still being called the same way
[23:24:48 CEST] <iive> yasm compilation , yes. dependency...
[23:25:34 CEST] <nevcairiel> why dont you just try it instead of speculating? :p
[23:25:39 CEST] <nevcairiel> it still works as before if you use yasm
[23:27:24 CEST] <iive> nevcairiel: my ffmpeg is using nasm, that's why.
[23:27:34 CEST] <nevcairiel> you can override that
[23:27:57 CEST] <nevcairiel> configure --x86asmexe=yasm
[23:28:30 CEST] <iive> maybe later... i don't feel like rebuilding everything.
[23:35:51 CEST] <funman> kierank: iiuc the h264context was different (1 per thread/field)
[23:36:41 CEST] <kierank> ah yes you are right
[23:37:33 CEST] <funman> but even -threads 1 showed different pointers
[23:38:21 CEST] <funman> did you try running h264_export_frame_props() for each field rather than only "second" field?
[23:40:02 CEST] <kierank> no, going to bed
[23:41:04 CEST] <funman> have sweet interlaced dreams
[23:56:48 CEST] <nevcairiel> jamrial: interestingly the linker error on msvc goes away if i disable debug linking .. but of course that fails to generate full debug symbols then, which is kinda one of the main reasons to use msvc :D
[23:57:36 CEST] <jamrial> nevcairiel: did you try reverting the strip commit from a week or so ago?
[23:57:41 CEST] <jamrial> maybe that's the problem
[23:57:49 CEST] <nevcairiel> i'll try that next
[23:58:09 CEST] <jamrial> 18f09524f7
[23:58:10 CEST] <nevcairiel> i thought maybe generating debug info in nasm might help, but it failed to do that and errored out on a bunch of files =p
[23:58:38 CEST] <jamrial> haha
[23:59:41 CEST] <jamrial> nasm seems to error on things yasm instead warns, though, like the x86inc stuff that reports sse instructions used in the wrong functions
[00:00:00 CEST] --- Sat Jul  8 2017