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

[burek]

[00:01] <BtbN> what, according to the debugger, the avctx pointer to my encoder init function is null oO
[00:02] <nevcairiel> dont trust the debugger too much, you're debugging optimized code afterall
[00:02] <BtbN> isn't the ffmpeg_g.exe unoptimized for debugging?
[00:02] <nevcairiel> its just un-stripped, still optimized
[00:02] <BtbN> hm, that complicates things
[00:02] <cone-897> ffmpeg.git 03Maxim Poliakovski 07master:cb2162adba40: g2meet: Rename FRAME_INFO to more appropriate DISPLAY_INFO
[00:02] <cone-897> ffmpeg.git 03Maxim Poliakovski 07master:3f826039ddcc: g2meet: factor out chunk seeking
[00:02] <cone-897> ffmpeg.git 03Maxim Poliakovski 07master:ae95b2f8103c: g2meet: Validate bpp and bitmasks in the display info
[00:03] <nevcairiel> in msvc i would just disable optimizations for the files i'm working on with a  compiler pragma
[00:03] <Compn> you can disable optimizations BtbN
[00:03] <BtbN> oh, it's even a configure option
[00:04] <BtbN> i started searching for the compiler flags
[00:04] <Compn> ehe :)
[00:04] <BtbN> i hope it works for msvc
[00:04] <Compn> ffmpeg has it because it has to independently test c-code vs cpu optimized code vs asm code .... 
[00:05] <Compn> or something like that
[00:05] <BtbN> i get a random segfault, after 100 lines which also access the avctx variable, and it tells me it's null
[00:05] <BtbN> doesn't realy make sense, so i guess it's just optimized out
[00:06] <Compn> the fun begins when it doesnt crash after you disable optimizations :)
[00:06] <BtbN> i coded a 700 line hardware encoder without running it once, there are hopefully a few obvious things i missed
[00:07] <JEEB> the most scary part is when something Just Works
[00:07] <JEEB> like my wrapper for the MS IStream interface
[00:07] <iive> BtbN: it might be memory overwrite/overflow. using stack protector and/or valgrind could help (if you run linux)
[00:07] <BtbN> only msvc currently
[00:07] <ubitux> also make sure you have an avclass in your local context struct if you're using avoptions
[00:07] <JEEB> yeah, windows doesn't exactly have valgrind-likes :s
[00:07] <JEEB> I hate that
[00:07] <ubitux> (common mistake...)
[00:08] <nevcairiel> you cannot turn off  optimizations globally with msvc
[00:08] <BtbN> ubitux, AVClass or AVClass* as first member?
[00:08] <ubitux> AVClass* yes
[00:08] <BtbN> yeah, that's present
[00:08] <nevcairiel> add ´#pragma optimize("", off)´ on top of your file and enjoy more useful code
[00:08] <BtbN> omg
[00:08] <nevcairiel> remove when done
[00:16] <BtbN> yay, it's no longer null
[00:30] <BtbN> seems like the nvenc devs never tested the IYUV input format
[00:30] <BtbN> it just randomly crashes from inside of a cuda dll if I just select that format
[00:30] <BtbN> selecting YV12 or NV12 works
[00:30] <BtbN> so just swapping the two planes it is
[00:33] <BtbN> hm, YV12 also crashes
[00:34] <nevcairiel> NV12 is typically the preferred hardware format, but its not a format very commonly used in ffmpeg tbh
[00:34] <BtbN> well, it offers support for YV12 and IYUV(==I420, the format ffmpeg uses)
[00:34] <BtbN> but it just crashes
[00:36] <BtbN> hm, no, it doesn't the api supports it, but not this specific implementation
[00:36] <BtbN> is there a way to set the pix_fmts of my AVCodec at runtime?
[00:44] <BtbN> hm, great. It needs an open encoder session to query the available formats
[00:44] <BtbN> which in turn needs an open cuda context
[01:34] <michaelni> ubitux, do you want to review a ffprobe patch (Re: [FFmpeg-devel] [PATCH] mjpegdec: parse JPS extension and save relevant stereo3d information)
[01:34] <michaelni> ?
[01:38] <ubitux> michaelni: only if you insist...
[01:38] <ubitux> i have no clue about mjpeg/jps/stereo3d :p
[01:39] <michaelni> ok, should i ask saste or do it myslef ?
[01:39] <michaelni> iam not really ffprobe maintainer
[01:39] <ubitux> ah, sure ask saste ;)
[01:40] <ubitux> BBB: uploaded fuzzed11.ivf ;)
[01:40] <BBB> argh
[01:41] <BBB> thread-only?
[01:41] <BBB> -threads 1 is clean here
[01:41] <ubitux> it seems
[01:41] <ubitux> and not that easy to trigger
[01:41] <BBB> so is -threads 2
[01:41] <ubitux> http://pastie.org/pastes/8713321/text
[01:42] <Compn> Gravity (2013).1080p.x265.mkv
[01:42] <Compn> 1080 hevc ? 
[01:42] <BBB> what's line 1304 again?
[01:42] <Compn> how is hevc decoding times compared to h264 ?
[01:42] <BBB> Compn: pretty awful
[01:42] <smarter> slow :]
[01:42] <smarter> multithreaded, but no asm yet (it's coming)
[01:42] <ubitux> BBB: pred = FFMIN(pred, refsegmap[(y + row) * 8 * s->sb_cols + x + col]);
[01:43] <BBB> hm...
[01:43] <JEEB> Compn, I hope that's done with --preset placebo + maxed out bframes and refs
[01:43] <BBB> and that's with my patch?
[01:43] <BBB> what threadcount?
[01:43] <JEEB> otherwise it's not gonna be better than x264, like, at all
[01:43] <BBB> I can't trigger it
[01:43] <ubitux> BBB: "auto" :/
[01:43] <ubitux> i'm trying to find an exact value triggering it
[01:44] <ubitux> i have 4 core HT (’ 8), any idea what value it's picking?
[01:44] <BBB> no :-
[01:44] <BBB> :-p
[01:44] <ubitux> ah, 9 does it
[01:44] <BBB> ah yes
[01:44] <smarter> JEEB: for the same bitrate?
[01:45] <JEEB> smarter, yes
[01:46] <JEEB> and if the build is older then even that isn't enough :P
[01:46] <smarter> did you test very low bitrates too?
[01:46] <JEEB> yes
[01:46] <Compn> ubitux : does HT actually act like another core (does it help) , or is it more mystery core (marketing hype) ?
[01:46] <ubitux> i see 8 core
[01:46] <ubitux> but there are actually only 4
[01:47] <Compn> but is there performance diff using 4 or 8 threads ?
[01:47] <ubitux> probably
[01:47] <JEEB> smarter, considering that x265 even just some very little time ago could NEVER be considered better than x264
[01:47] <Compn> stupid question from me probably :)
[01:47] <smarter> JEEB: that's interesting, I'm doing some x264/vp9 comparaison at low bitrates and as expected h264 falls apart and vp9 stays watchable
[01:48] <smarter> JEEB: with preset placebo for x264, and --good --speed 0 for libvpx
[01:48] <JEEB> the fact that you can now kind of get some (?) results out of it if you max it out
[01:48] <ubitux> --speed 0 unleash the speed with libvpx?
[01:48] <JEEB> is kind of great already
[01:49] <smarter> ubitux: I meant --good --cpu-used 0 actually
[01:49] <smarter> ubitux: which means "slowest setting which is still usable"
[01:49] <JEEB> although the lowest I've gone so far is ~415kbps for 720p
[01:49] <JEEB> dunno if that is "low enough" for you :)
[01:50] <smarter> JEEB: I just encoded the Sintel trailer at 67kbps 480p :)
[01:50] <smarter> now doing some 720p
[01:50] <JEEB> but x264 was getting a bit derpy at that point already so I would guess the results would be similar with lower rates as well
[01:51] <JEEB> http://abload.de/img/matched_visual_opt7ryvz.png http://abload.de/img/checking00173789z9e.png
[01:51] <JEEB> you can guess which is which
[01:51] <Compn> i liked jasons' ultra low bitrate x264 tests
[01:51] <Compn> with low motion video 
[01:52] <JEEB> Compn, those then later sparked lachs0r's floppy sized tora dora encode
[01:52] <JEEB> a full anime episode floppy-sized
[01:52] <Compn> lol oh man wheres that ?
[01:52] <JEEB> with audio!
[01:52] <ubitux> JEEB: watashi, kininarimas'~
[01:52] <Compn> i want to see 1.44mb episode :D
[01:53] <JEEB> http://tmp.srsfckn.biz/floppy_tiger.mkv
[01:53] <JEEB> 1.28 MB (1,342,980 bytes) not exactly 1.44
[01:53] <ubitux> (http://lucy.pkh.me/kininarimas.webm)
[01:54] Action: ubitux runs away
[01:54] <Compn> hmm, why cant i play that mkv
[01:54] <Compn> wrong colorspace
[01:54] <J_Darnley> Dammit FF!  I don't want you to play the video!
[01:55] <JEEB> ubitux, I love it how that most probably is based on my cap :P
[01:55] <JEEB> see the station logo
[01:55] <ubitux> JEEB :D
[01:55] <ubitux> heh, i have no audio with ffplay on floppy_tiger.mkv
[01:56] <ubitux> but i do with mpv
[01:56] <Compn> you are missing speex decoder
[01:56] <ubitux> oh we don't have a native decoder
[01:56] <ubitux> sadness
[01:56] <Compn> shhhh , someone will hear you and decide to code one up
[01:57] <Compn> also i am dissapoint at the quality of that encode
[01:57] <Compn> i'm not sure what i was expecting
[01:57] <JEEB> :D
[01:57] <Compn> i guess more.
[01:57] <JEEB> b-b-but it fits on a floppy!
[01:57] <ubitux> vf_pp to the rescue
[01:57] <JEEB> :D
[01:58] <J_Darnley> What did I expect?!
[01:58] <J_Darnley> That is the second worst video I've ever seen
[01:58] <JEEB> :D
[01:58] <JEEB> I guess I could encoding something like that with any of the new formats
[01:58] <JEEB> *could try
[01:58] <ubitux> it's missing subtitles :(
[01:59] <JEEB> ubitux, I bet those could actually fit
[01:59] <JEEB> since it's under 1.44MB by itself
[01:59] <J_Darnley> They'd probably fill those remaining KB
[01:59] <Compn> nut would have less container overhead? :P
[01:59] <ubitux> JEEB: i want them hardsubbed
[01:59] <Compn> it has to be 480p too
[01:59] Action: J_Darnley goes back to testing
[02:00] <ubitux> hey wait there is actually the full episode
[02:00] <ubitux> that's pretty impressive by itself
[02:00] <JEEB> yup
[02:00] <JEEB> only OPED are missing
[02:03] <J_Darnley> Dammit cygwin!  Stop dieing every time you fork!
[02:10] <ubitux> BBB: the code is much more resistant to fuzzing since your latest patch :)
[02:10] <ubitux> i think i'll stop fuzzing after the next one
[02:13] <ubitux> BBB: ah btw, with assert-level, Assertion pred < 8 failed at /home/ubitux/src/ffmpeg/libavcodec/vp9.c:1305
[02:13] <ubitux> assert-level=2*
[02:20] <ubitux> (1 should be enough)
[02:24] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:f90a4bfc43c9: mlpdec: fix request_channel_layout behavior.
[02:24] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:73be2ebe96ee: Merge commit 'f90a4bfc43c9192e89d9b4c81d80789cd9b38a2f'
[02:47] <BtbN> http://bpaste.net/show/lOvUv58DFdyrNBaXBs3s/ Why is it complaining about the pts beeing less than the dts?
[02:48] <BBB> ubitux: fixed differently
[02:49] <BBB> ubitux: new patch to fix both fuzzed10 and fuzzed11 (it's the same bug essentially)
[03:01] <cone-897> ffmpeg.git 03Tim Walker 07master:c1e7de8f62c7: mlp_parser: fix request_channel_layout behavior.
[03:01] <BtbN> hm, just adding an offset to the pts seems to work. 
[03:01] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:4040b56f5afd: Merge remote-tracking branch 'qatar/master'
[03:01] <BtbN> But no idea if it's the right solution
[03:03] <BBB> BtbN: [nvenc @ 0000004E5C0ED020] Wrote B frame with pts: 1, dts: 2
[03:03] <BBB> BtbN: 1 < 2 that's why
[03:04] <BtbN> yeah, but shouldn't that be ok?
[03:04] <BBB> the order should be (for input 0, 1, 2, 3; in order of pts; dts): 0, 0; 3, 1; 1, 1; 2, 2
[03:04] <BBB> so you see the dts actually repeats, which is fine
[03:05] <BBB> like I said, dts will be min(pts, remaining_input_ts[@])
[03:06] <BBB> so dts can never be greater than pts
[03:06] <BBB> dts is always min of all following (including this one) pts, ever
[03:07] <BtbN> hm, no. It doesn't like the dts repeating
[03:07] <BtbN> [mp4 @ 0000001B601DB240] Non-monotonous DTS in output stream 0:0; previous: 201472, current: 201472; changing to 201473. This may result in incorrect timestamps in the output file.
[03:09] <BBB> michaelni: ^^ ?
[03:10] <BBB> timestamps give me the creeps
[03:11] <BtbN> just substracing the number of B frames from the dts works. But doesn't seem like the right solution
[03:23] <michaelni> BtbN, does it work if you dont set the dts ?
[03:25] <BtbN> michaelni, so, allways setting it to 0?
[03:25] <michaelni> AV_NOPTS_VALUE
[03:25] <michaelni> and if that doesnt work you can calculate them, they are basically sorted pts more or less
[03:26] <BtbN> yeah, sorting them is what i did before, it didn't work because some of them ended up beeing <pts
[03:26] <BtbN> Setting it to NOPTS_VALUE leads to [mp4 @ 00000027A29B5580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 768 >= 256
[03:27] <michaelni> BtbN, you must set has_b_frames to the reorder buffer size
[03:28] <michaelni> its 1 for mpeg2 style bframes and 2 for that 1 level b pyramid thing
[03:28] <BtbN> does the dts allways increse by 1 each frame?
[03:30] <michaelni> if your material is constant fps with no droped frames then yes for mpeg1/2/mpeg4-asp dts, iam not 100% about h264 they possibly allow funky things
[03:30] <michaelni> but dont waste your time on "funky things" thats probably not relevsant here
[03:31] <BtbN> yeah, just substracing the number of B frames from the dts makes it work
[03:31] <michaelni> its wrong though if fps isnt constant
[03:33] <michaelni> did you try dts == NOPTS_VALUE with correctly set has_b_frames ?
[03:33] <BtbN> not yet
[03:36] <BtbN> yes, seems to work
[03:39] <BtbN> Now i have to find out why it uses 80% CPU power while only doing 200 fps
[03:45] <BtbN> the encoder works fine now, hm
[03:45] <BtbN> but it is way too slow
[03:45] <BtbN> and uses way too much cpu
[04:14] <lukaszmluki> can someone give a hint where to find conversion yuv420p->yuv444p12le?
[04:37] <BtbN> Is it possible to tell ffmpeg to put the decoder and encoder into seperate threads?
[05:12] <andrewrk> BtbN, you mean with the ffmpeg command?
[05:13] <BtbN> yeah
[05:13] <andrewrk> I think you would have to write your own code
[05:14] <andrewrk> pardon my self-promoting here but... I have a library that sits on top of ffmpeg and provides encoding with a separate thread for decoding and encoding.
[05:14] <andrewrk> https://github.com/andrewrk/libgroove
[05:14] <andrewrk> may or may not be of use to you
[05:14] <BtbN> hm, cause it currently seems like the decoder is using up most of the performance
[05:15] <BtbN> and as the nvenc encoder isn't multithreaded, it's quite limited by that
[05:16] <BtbN> i'd have to get libx264 support in there, so i can compare it
[05:17] <andrewrk> oh don't look at the thing I linked you then. it's audio only
[05:22] <BtbN> 60% of the time is spent in 
[05:22] <BtbN> decode_slice in h264.c. The other 40% is spent in memcpy.
[12:49] <michaelni> BtbN, some decoders and some encoders use multiple threads
[13:01] <michaelni> i havnt really looked at your code at all but if its slower than expected first i would make sure the encoder has enough frames so it has something to work with and isnt limited to encoding one frame during the time the wraper executes on the cpu
[13:22] <BBB> ubitux: wanna review latest round of patches on ML? Also see github (https://github.com/rbultje/ffmpeg/commits/vp9-context-opts)
[13:22] <BBB> ubitux: github has one further patch that helps simd somewhat
[13:23] <ubitux> yes i had a quick look and it looked nice
[13:23] <BBB> \o/
[13:23] <BBB> no more fuzz issues?
[13:23] <BBB> (after that last patch)
[13:24] <ubitux> so far, no, but i stopped
[13:24] <ubitux> i'll make a new run after this patchset
[13:24] <ubitux> and i guess we should be done with it
[13:24] <BBB> maybe I should email that google guy and ask him to do some cluster fuzzing
[13:24] <ubitux> that's what i was going to suggest
[13:24] <ubitux> :D
[13:24] <BBB> lol
[13:24] <BBB> we also still do need intra pred assembly
[13:24] <BBB> and prefetch
[13:25] <ubitux> i won't have much free time in the following weeks to work on vp9
[13:25] <ubitux> but i'll at least do a benchmark when i'll get my avx2 hw
[13:26] <ubitux> if it's faster than libvpx even without avx, i guess we could start publishing the bench
[13:26] <ubitux> otherwise... i'll try to write some asap :p
[13:32] <Skyler_> FYI you can use the Intel SDE to write avx2 even without an avx2 CPU
[13:33] <Skyler_> it's not perfect since you can't, like, actually benchmark it, but it lets you get quite a bit done at least
[13:34] <burek> trac still doesn't work? :(
[13:34] <Skyler_> great if you're terribly impatient about asm ;)
[13:36] <burek> is there any help needed to get the trac up and running again?
[13:36] <ubitux> Skyler_: good to know, but i think i'll just wait a little :)
[13:38] <BBB> Skyler_: it's much more fun if you can see the results
[13:44] <Skyler_> true, true!
[13:46] <BBB> and latest mbps have haswell from what I gather, so maybe I should upgrad
[14:06] <wm4> someone wants mplayer's vf_tfields, because it's so fast :/
[14:06] <wm4> where did the libmpcodecs filter go?
[14:10] <wm4> apparently it was never part of the libavfilter internal libmpcodecs
[14:11] <wm4> even though it's in mplayer
[14:12] <wm4> user wants a deinterlacer that's faster than yadif
[14:13] <wm4> libpostproc's bob deinterlacer is out because it doesn't double the frame rate
[14:14] <nevcairiel> use vf_separatefields? :p
[14:15] <Daemon404> wm4, anything faster will look pretty back
[14:15] <Daemon404> bad*
[14:16] <nevcairiel> there is also vf_kerndeint, no idea how it compares in speed/quality
[14:16] <wm4> separatefields looks pretty straight-forward
[14:16] <nevcairiel> it'll have severe bobbing though
[14:17] <wm4> oh, separatefields doesn't fill the missing lines
[14:17] <wm4> so it's half-res
[14:17] <nevcairiel> easy enough to add a scale filter
[14:18] <BBB> then it loses it's fast
[14:18] <nevcairiel> in point scaling mode? :D
[14:18] <BBB> speaking of awful
[14:19] <wm4> here's an evil idea: use separatefields and adjust the PAR to double the pixel height, let the video driver do the rest
[14:19] <nevcairiel> cant you let the video driver deinterlace in the first place
[14:19] <wm4> apparently this isn't possible in this case
[14:30] <J_Darnley> Uhh... separating fields with a dumb resize will produce horrible bobbing.
[14:31] <nevcairiel> he asked for fast, not pretty
[14:31] <wm4> well, I'm not sure what the user actually wants
[14:31] <kierank> wm4: use yadif with some of the speedups
[14:31] <wm4> which speedups?
[14:32] <nevcairiel> ignore spatial checks or what its called
[14:32] <kierank> yeah
[14:32] <nevcairiel> or just output 1 frame per two fields :p
[14:32] <wm4> nah, user wants 1 frame per field for some reason
[14:32] <nevcairiel> hand him a C compiler
[14:33] <kierank> wm4: that "some reason" is know as proper deinterlacing
[14:33] <wm4> he has one, and he made a patch to add yucky mplayer code (vf_tfields) back to my code
[14:33] <kierank> with correct temporal resolution
[14:33] <wm4> what does temporal resolution matter if it looks like crap anyway?
[14:34] <iive> wasn't there an idea for crt like deinterlace? aka separate the fields into frames, but don't bother with filling the gaps and keep them black
[14:34] <iive> let the human eye, LCD latency fill the gaps.
[14:35] <nevcairiel> that might work if you output  unscaled, if you start scaling afterwards it will probably result in terrible artifacts
[14:35] <iive> you should just use interlaced scalling.
[14:35] <nevcairiel> not sure the pesistence of vision is strong enough for that to work
[14:35] <iive> and encode the result as interlaced too.
[14:45] Action: J_Darnley should test that in avisynth
[14:51] <Daemon404> vlc clones at 90 mbit/s... nice
[14:52] <wm4> btw. what's the deal with git://source.ffmpeg.org/ffmpeg.git
[14:52] <wm4> it's so slow
[14:52] <wm4> is it different from the videolan repo?
[14:52] <Daemon404> i dont know
[14:53] <ubitux> wm4: no it's the same
[14:53] <ubitux> afaik
[14:54] <Daemon404> Receiving objects:  32% (135317/419525), 83.57 MiB | 10.04 MiB/s
[14:54] <Daemon404> not ffmpeg, but i get the same for ffmpeg
[15:04] <burek> is there any info about trac?
[15:04] <burek> what's going on and when (if) is it gonna be up again?
[15:07] <kierank> wm4: try watching sports
[15:08] <kierank> better to see some quality issues than to get a headache
[15:08] <kierank> J_Darnley: vlc has a "deinterlacer" that simulates persistence of vision
[15:13] <Daemon404> michaelni, ping
[15:16] <michaelni> Daemon404, source.ffmpeg.org is videolan
[15:16] <Daemon404> nah thats not why im pinging you
[15:16] <Daemon404> do you mind if i push the raw hevc demuxer patch to ffmpeg (you looked at it months ago)
[15:17] <Daemon404> its just registering it in rawdec.c and pals
[15:17] <michaelni> sounds harmless
[15:17] <Daemon404> ok :)
[15:17] <Daemon404> im preparing to revive my x265 patch
[15:18] <michaelni> cool
[15:18] <Daemon404> now that its semi-ok
[15:19] <smarter> what about kvazaar? :)
[15:19] <Daemon404> its not useful yet
[15:19] <JEEB> kvazaar needs clean-up
[15:19] <Daemon404> x265 is actually outperforming x264 in some respects now
[15:20] <Daemon404> at least on some limited testing
[15:20] <Daemon404> i dont think kvazaar has a real API yet either?
[15:20] <JEEB> after kvazaar gets all of the encoder internals out of main() and an actual API a patch can be made for it
[15:20] <JEEB> yeah
[15:21] <BBB> lol x265
[15:21] <BBB> and people complain about google being corporate
[15:21] <BBB> "stop using my original, self-devised, trademarked(sic) name or we'll sue you"
[15:22] <Daemon404> BBB, they got the rights from x264/json
[15:22] <JEEB> yeah, I think MCW is on the level of google or worse with regards to community'ing, and of course the PR person has to make it even harder for it to get into it
[15:23] <Daemon404> jason*
[15:29] <cone-814> ffmpeg.git 03Derek Buitenhuis 07master:ef5d32b9c531: Add raw HEVC muxer
[15:35] <Daemon404> nevcairiel, i see vlc has a hardcoded check for your toolchain
[15:35] <Daemon404> with your name and all
[15:35] <nevcairiel> really, what for
[15:35] <Daemon404> i dont know
[15:35] <Daemon404> but it does.
[15:35] <nevcairiel> its not like it has any special patches
[15:36] <Daemon404> i know
[15:36] <JEEB> I remember bringing it up on #videolan as a simple thing to use for a win32 mingw-w64 toolchain
[15:36] <JEEB> so it probably goes back to that
[15:36] <Daemon404> oic
[15:36] <nevcairiel> link? :p
[15:36] Action: Daemon404 still uses his own :P
[15:37] <nevcairiel> that reminds me that i wanted to build a new one with the mingw-w64 3.1 release, but i looked it up and most changes are only in their broken winpthreads thing which i dont build anyway =P
[15:38] <Daemon404> wait it might be in msys O.o
[15:38] <Daemon404> its in /!components.txt
[15:38] <Daemon404> whatever that is
[15:38] <nevcairiel> oh
[15:38] <nevcairiel> thats just Xs package then, he includes that file with all the package versions of msys, and my mingw toolchain
[15:38] <Daemon404> im not using his
[15:38] <Daemon404> i used mingw-get
[15:39] <nevcairiel> weird
[15:39] <nevcairiel> never used that
[15:39] <nevcairiel> maybe thats why so many people download my package
[15:39] <nevcairiel> i always wondered
[15:39] <Daemon404> lol
[15:39] <nevcairiel> (i analyze apache logs!)
[15:41] <nevcairiel> i even got a request to enable fortran in my builds once
[15:41] <Daemon404> lol yeah
[15:42] <wm4> how broken is this winpthreads thing?
[15:42] <JEEB> it is
[15:42] <JEEB> it tries to be a higher-level wrapper
[15:43] <nevcairiel> havent tried it recently, maybe they fixed the worse things, but it used to just crash and if it didnt have terrible performance
[15:43] <JEEB> but it ends up just being slow
[15:43] <nevcairiel> pthreads-w32 is much better
[15:43] <JEEB> yeah, I didn't get the crashes but it was slow as molasses
[15:43] <wm4> I looked at its code once, and it seems they have to do half a dozen of low level locks for a simple pthreads lock
[15:43] <Daemon404> last thing i tried with winpthreads didnt even build
[15:43] <Daemon404> so back to pthreads-win32 it was
[15:45] <nevcairiel> I only really use pthreads because of this worker thread in the UDP code, should revive the ML thread to make it more generic
[15:46] <nevcairiel> otherwise the win32threads layer in ffmpeg would be enough
[15:46] <wm4> doesn't this worker thread thing rely on cancellation?
[15:46] <wm4> well, apparently it works anyway
[15:47] <nevcairiel> yeah which the native thread API doesn't take too kindly, but pthreads-w32 implemented it somehow
[15:51] <Daemon404> jesus
[15:51] <Daemon404> running vlc's configure on windows trashed my system
[15:51] <Daemon404> i had to hard reboot
[15:52] <Daemon404> infinite loop of ./ABOUT-NLS: command not found
[15:52] <Daemon404> somehow screwed me
[15:52] <wm4> fork bomb on windows?
[15:52] <Daemon404> yea
[15:53] <nevcairiel> running such configures can be evil, as you can't even simply stop it by closing the console window
[15:53] <Daemon404> yep
[15:53] <Daemon404> my rdp actually froze
[15:53] <nevcairiel> the windows command prompt closes, but it doesnt take the sh with it
[15:53] <Daemon404> had to kill it IRL
[15:53] <Daemon404> with my hands
[15:54] <Daemon404> i wonder why the hell its trying to run a damn text file
[15:54] <nevcairiel> all scripts are just text files
[15:55] <Daemon404> a text file with english in it
[15:55] <Daemon404> maybe vlc doesnt like out of tree builds...
[15:58] <Daemon404> it explodes at "checking if dolt supports this host"
[16:03] <Daemon404> it's some sort og globbing failure
[17:16] <cone-814> ffmpeg.git 03mrlika 07master:36a629795370: avcodec/dvbsubdec: DVB subtitles decoder: support of 5 bytes extradata format
[17:16] <cone-814> ffmpeg.git 03Ramiro Polla 07master:5965adeb2047: lavd: add decklink output device
[17:24] <kurosu_> regarding the x265 trademark, I've heard that, despite the equivalent of relevant prior art (people having websites or s/w with x265 in the name, related to a h265 encoder), there is a case here of the typical uspto "first to file" case
[17:24] <kurosu_> it's even stronger for trademarks, I've been told
[17:50] <kierank> kurosu_: it's not as simple because vlc has the trademark in eu and gb
[17:50] <kierank> whereas mcw have it in usa
[17:50] <kurosu_> for x265 ?
[17:50] <kierank> yes
[17:51] <kurosu_> I think I've seen mcw ask for it around last summer, right ? it would still be up for dispute, I gues
[18:08] <ubitux> BBB: so, you branch is mergeable?
[18:09] <BBB> I think sp
[18:09] <BBB> o
[18:10] <ubitux> gonna do a few test and push
[18:10] <BBB> ty
[18:10] <BBB> i have 11 simd intra pred funcs to write
[18:10] <BBB> almost done
[18:13] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:9aeca1c572dc: vp9: just disallow temporal or no-update segmentation on size-change.
[18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:cdfcd0612601: vp9: coef context reading optimization.
[18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:0c30c8ddc138: vp9: faster skip-block coefficient blanking.
[18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:1dc8559e25b4: vp9: more aligned zeroes.
[18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:fccd7d81b694: vp9: decode_mode context optimizations.
[18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:45245e202ef1: vp9: coef decoding context-splat speedup.
[18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:37c6eac296ba: vp9: remove memset in loopfilter level setting loop.
[18:14] <cone-814> ffmpeg.git 03Ronald S. Bultje 07master:0d4d223353b7: vp9: invert order in l[] intra prediction array.
[18:14] <BBB> \o/
[18:14] <BBB> ok
[18:16] <BBB> let's finish the intra pred simd, that's the big thing now
[18:17] <ubitux> http://pastie.org/pastes/8715662/text
[18:17] <ubitux> slowest remaining C func is dc_32x32_c
[18:17] <BBB> cool
[18:18] <BBB> I have simd for that one already
[18:18] <ubitux> :)
[18:18] <BBB> feel free to try all sort of weird stuff to make decode_coeffs_b faster
[18:18] <BBB> jason's idea was pretty good
[18:19] <BBB> i.e. instead of saving N (literal) for context and using N+M+1>>1 as next-coef-context, save 2*N+1 (literal) as context and do N+M>>2 (note the +1 is missing)
[18:19] <BBB> the lack of the +1 should help speed (missing inc in each contextualization)
[18:20] <BBB> also the division by 2 (for tx32) can be moved outside the decode_coeffs_b calling loop in decode_coeffs
[18:20] <kurosu_> if dc_32x32_c is the slowest function, I guess that a good sign :)
[18:20] <Skyler_> I'm surprised decode_coeffs uses up so much time (the non-b part), I wonder where that's all going
[18:21] <Skyler_> does inlining decode_coeffs_b help?  or is it the memsets maybe?  I don't have a proper profiler on me at least
[18:22] <BBB> I just removed the memsets
[18:22] <BBB> they were part, so removing them helped a bit
[18:22] <BBB> but there's still a lot of expensive bookkeeping in there
[18:22] <BBB> vp9 coef decoding isn't exactly light-weight as it was in vp8
[18:23] <BBB> ubitux: on that sample (etv5k), how much faster are we than libvpx?
[18:23] <Skyler_> I wonder if stuff like lines 2058-2065 could be made faster by templating it based on the transform size
[18:23] <Skyler_> since you could make the logic more efficient if you knew what etp1d was
[18:23] <Skyler_> *step1d
[18:23] <ubitux> BBB: can you provide a libvpx cmd line?
[18:24] <ubitux> BBB: with & without threading?
[18:26] <ubitux> BBB: vpxdec bla.webm -o /dev/null, anything faster? :)
[18:27] <wm4> are there actually audio codecs that have "key frames"? this seems to imply yes, but unsupported: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/utils.c;h=c8fd8c65fc8fc8908196f9d56e1f46e28a8b6c5d;hb=HEAD#l1726
[18:29] <wm4> or better worded: audio codecs that have non-keyframes
[18:29] <BBB> ubitux: ffmpeg -c:v libvpx-vp9 -threads 1 -f null -
[18:29] <nevcairiel> truehd/mlp has major sync frames which are required to start decoding
[18:29] <ubitux> BBB: mmh, i should probably make a build with a recent libvpx
[18:30] <BBB> yes
[18:30] <BBB> Skyler_: yeah that was one of my ideas, esp. for the uv (because for e.g. tx32x32, you don't actually need to loop anymore, you can only fit one, thus skipping all loop setup)
[18:30] <wm4> there's no mlp encoder I guess
[18:31] <BBB> Skyler_: and as I sugested to ubitux before, move division by 2 in decode_coeffs_b out of loop by moving it into the calling branch outside the caller loop in decode_coeffs
[18:31] <ubitux> ./ffmpeg -v 0 -nostats -i ~/samples/vp9/etv5k/etv5k.webm -f null -  63.88s user 0.62s system 224% cpu 28.669 total
[18:31] <ubitux> ./vpxdec ~/samples/vp9/etv5k/etv5k.webm -o /dev/null  62.14s user 0.36s system 99% cpu 1:02.58 total
[18:31] <BBB> like if (tx=32x32) { for .. for .. decode_coeffs_b_32x32 }
[18:31] <BBB> ubitux: you're using threading, that's cheating
[18:32] <BBB> ubitux: use -threads 1 (and whatever the equivalent in libvpx is)
[18:32] <ubitux> BBB: yes, running
[18:32] <Skyler_> BBB: I wonder if avoiding that branch is worth the extra code size, I guess test it at least
[18:32] <ubitux> BBB: vpxdec is not threaded oO
[18:33] <Skyler_> geez, I wonder why they did that though.   why couldn't they have just divided qmul by two
[18:33] <Skyler_> such a weird choice
[18:33] <ubitux> ./ffmpeg -v 0 -nostats -threads 1 -i ~/samples/vp9/etv5k/etv5k.webm -f null -  48.57s user 0.03s system 99% cpu 48.653 total
[18:34] <ubitux> ./vpxdec ~/samples/vp9/etv5k/etv5k.webm -t 1 -o /dev/null  62.76s user 0.34s system 99% cpu 1:03.17 total
[18:34] <ubitux> (git/master for both)
[18:35] <wm4> indeed, truehd mkv files have the key frame flag only set on some packets, but remuxing truehd with ffmpeg sets the flag on every packet :(
[18:39] <wm4> well, still better than this lavf muxed mkv sample file I have here that doesn't have the key frame flag set on any packets
[18:40] <BBB> ubitux: it is - loopfilter and tile threading
[18:40] <BBB> not frame
[18:41] <ubitux> ah, k
[18:41] <BBB> loopfilter is default, it doesn't help much
[18:41] <BBB> like 5% or 10% or so
[18:41] <BBB> (after lf simd)
[18:41] <ubitux> BBB: Carl spotted compilation problem, i'll fix in a second unless you want to
[18:41] <BBB> also their lf is way slower than ours, most of ours acts on 16px at a time (typical sse2 stuff), theirs is mostly 8px at a time
[18:41] <BBB> go ahead, I'm not doing anything
[18:42] <BBB> actually I'm hungry
[18:42] <BBB> anyway 30% faster is pretty good
[18:44] <kurosu_> indeed, impressive
[18:44] <kurosu_> I've been asked by first-timer at asm how much good asm can bring - I get my reply here
[18:45] <cone-814> ffmpeg.git 03Clément BSsch 07master:c333987876ba: vp9: fix compilation with !HAVE_FAST_64BIT.
[18:46] <kurosu_> I fear the initial structure is also a key element
[18:47] <kurosu_> I fear there may be bottlenecks with the current hevc implementation
[18:48] <kurosu_> in particular, last I checked, there was a lot of unnecessary buffering, from those (x, y) addressing to the buffer
[18:49] <Daemon404> [17:42] <@BBB> anyway 30% faster is pretty good <-- but isnt it 64-bit only
[18:49] <Skyler_> writing 32-bit versions of some of that asm looks very exciting
[18:49] <Daemon404> i would have though chrome would be ffvp9's main use case
[18:49] <Daemon404> i.e. 32-bit
[18:50] <nevcairiel> you dont think google use their own decoder? :p
[18:50] <Daemon404> who knows
[18:50] <BBB> kurosu_: right, it's both
[18:50] <BBB> Daemon404: it's not hard to write 32bit asm
[18:50] <BBB> Daemon404: I just don't care
[18:51] <BBB> I guess I'm trying to give chrome incentive to switch to 64bit
[18:51] <Daemon404> o/
[18:51] <Daemon404> lol yeah right
[18:51] <BBB> still being 32bit is about as laughable as the hevc-vp9-x264 comparisons I've seen so far
[18:51] <Daemon404> same for steam (which uses chromium)
[18:51] <BBB> cargo cult etc.
[18:52] <Daemon404> i dont know how many people still run 32bit windows
[18:52] <BBB> fuck 'em
[18:52] <BBB> tell them to upgrade
[18:52] <Daemon404> prett sure a leading browser isnt going to take that stance
[18:52] <BBB> why do we all need the newest iphone and samsung galaxy, but a 10year old windows is ok?
[18:53] <wm4> because windows is not a status symbol
[18:53] <Skyler_> I'm guessing still being 32-bit might have to do with a combination of required libs being 32-bit, 32-bit sandboxing code (segmentation doesn't work in long mode), the JIT, and stuff like that?
[18:53] <Daemon404> Skyler_, the JIT works perfectly fine in 64bit
[18:53] <Daemon404> thats how node.js uses it.
[18:53] <Skyler_> okay so they did at least port that
[18:54] <Daemon404> all of chrome woks in 64bit
[18:54] <Daemon404> because OS X is 64bit
[18:54] <Daemon404> chrome too iirc
[18:54] <nevcairiel> they dont want to go full 64-bit yet because all their security testing didnt cover it yet
[18:54] <kierank> Daemon404: seems they announce coaches by twitter
[18:54] <Daemon404> they == ?
[18:54] <kierank> fgw
[18:54] <Daemon404> FGW?
[18:54] <Daemon404> o ok
[18:55] <Daemon404> i have a backup (proper) coach booked
[18:55] <Daemon404> i am *not* missing my nyc trip due to england not being able to handle rain, of all things
[18:55] <Daemon404> :V
[18:55] <nevcairiel> which is kinda amusing, as thats the weather you think about when someone mentions england
[18:56] <Daemon404> the irony is lost on a lot of brits i talk to.
[18:56] <kierank> Daemon404: to be fair the railway held firm for 160 years
[18:56] <kierank> brunel being the great man he is
[18:56] <Daemon404> ... it's flooded the last 3 years ive been here
[18:56] <Daemon404> ive been trapped every single year
[18:56] <Daemon404> due to rain
[18:56] <nevcairiel> maybe being 160 years old is the issue at hand? :D
[18:56] <kierank> i was trapped last year
[18:56] <smarter> chromium in every 64 bits linux distribution is 64 bits, but release a 32 bits and a 64 bits Windows executable is probably confusing for people
[18:56] <Daemon404> nevcairiel, poor design choices 160 years ago
[18:56] <kierank> well vlc is 32-bit no?
[18:57] <Daemon404> kierank, its both now
[18:57] <Daemon404> but no win64 ssl
[18:57] <Daemon404> because lollicenses
[18:57] <nevcairiel> license is different in 64-bit?
[18:57] <Daemon404> win64 needs a newer gnutls or whatever
[18:57] <Daemon404> which has lgplv3 deps
[18:57] <Daemon404> or something
[18:57] <Daemon404> gpl fun.
[18:58] <kierank> i need to buy food but it's raining :(
[18:58] <Daemon404> kierank, the olympics on vt are hilariou
[18:58] <kierank> why?
[18:58] <Daemon404> brits are losing their shit over a bronze medal win
[18:59] <Daemon404> "brits 23rd medal in the winter olympics since 1920"
[18:59] <Daemon404> just lol.
[18:59] <kierank> we don't have snow you know
[18:59] <Daemon404> northern england gets snow usually
[18:59] <Daemon404> iirc
[18:59] <kierank> not enough to train year round
[18:59] <Daemon404> no county does, except maybe russia
[19:00] <Daemon404> country*
[19:00] Action: Daemon404 dinner &
[19:55] <cone-814> ffmpeg.git 03Derek Buitenhuis 07master:722554788b77: Add raw HEVC muxer
[19:55] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:ffe987b96dd4: Merge commit '722554788b77c13748e83458f626a9ac38b70072'
[19:58] <ubitux> smarter: i don't know if i should laugh or cry reading what you said
[19:59] <ubitux> it's certainly true that a huge part of the people downloading chrome wouldn't be able to choose what download button to clic between 32 and 64 bit
[20:03] <cone-814> ffmpeg.git 03Maxim Poliakovski 07master:bc3f03567a04: g2meet: rename FRAME_INFO to more appropriate DISPLAY_INFO
[20:03] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:5b23c7ed6fa9: Merge commit 'bc3f03567a04a9f7e412bcf2ca09c163f3f13941'
[20:03] <JEEB> hmm
[20:04] <Daemon404> ubitux, you can discern wordize from the user agent
[20:04] <Daemon404> word size*
[20:06] <ubitux> sounds like win64 is really fun anyway
[20:07] <JEEB> oh, how fun. mp4 has all MPEG-1 audio muxed in the same way so you have parse it
[20:08] <kierank> Daemon404: but it would be a pita  to coordinate plugins
[20:08] <JEEB> and mp4box loved to break mp3 streams somehow when muxing
[20:08] <JEEB> and the broken packet leads to a misparse as mp1
[20:09] <Daemon404> gpac? break stuff?
[20:09] <Daemon404> NO WAY
[20:09] <Daemon404> never.
[20:10] <JEEB> inorite
[20:10] <JEEB> http://fushizen.eu/samples/mp3_parsed_as_mp1.mp4
[20:10] <Daemon404> mp1? ive never seen that in the wild even...
[20:10] <BtbN> How do i tell the configure script where to look for libx264 libs and headers?
[20:11] <JEEB> --extra-cflags="-I/your/prefix/include" --extra-ldflags="-L/your/prefix/lib"
[20:11] <Daemon404> no!
[20:11] <Daemon404> no no no !
[20:11] <Daemon404> use pkg-config properly.
[20:11] <JEEB> or you use PKG_CONFIG_PATH
[20:11] <BtbN> pkg-config on windows?
[20:11] <ubitux> won't work
[20:11] <BtbN> with msvc?
[20:11] <Daemon404> BtbN, yes
[20:11] <Daemon404> ah msvc
[20:11] <ubitux> we're not using pkg-config to probe
[20:11] <Daemon404> ubitux, oic
[20:11] <JEEB> and yeah, pkg-config isn't used for libx264
[20:11] <JEEB> :P
[20:11] <ubitux> i sent a patch for using pkg-config
[20:12] <ubitux> carl didn't like it much
[20:12] <ubitux> i didn't insist
[20:12] <Daemon404> imo pkg-config is more correct
[20:12] <ubitux> i agree
[20:12] <Daemon404> BtbN, you need an msvc-compatible .lib file
[20:12] <Daemon404> named x264.lib
[20:12] <BtbN> i have that(just built it myself)
[20:12] <Daemon404> ah ok
[20:12] <Daemon404> then use what JEEB said
[20:12] <Daemon404> *or*
[20:12] <Daemon404> set %LIB% and %INCLUDE%
[20:13] <JEEB> yeah, I think with msvc it's simpler to use the system variables
[20:13] <JEEB> I tried to use extra-c/ldflags myself before with msvc
[20:13] <Daemon404> its easier to set before launching bash
[20:13] <JEEB> gave up
[20:13] <JEEB> :V
[20:15] <cone-814> ffmpeg.git 03Andrew Kelley 07master:b0c2c097e422: lavf: default .ogg audio to libvorbis if we can
[20:15] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:cf0e5b7fd4d1: Merge commit 'b0c2c097e422b9e10a7d856582f8321d28af821e'
[20:15] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:28caf13ac394: fate: fix lavf-ogg test
[20:18] <BtbN> libx264 is faster than nvenc, but only because it can use all 4 cores
[20:18] <Daemon404> im sure it is also significant better quality.
[20:18] <Daemon404> nvenc produced crap last time i saw.
[20:18] <BtbN> it's ok for what it's designed for
[20:19] <BtbN> its main purpose is real time streaming
[20:20] <Daemon404> x264 has been used extensively for that (and also has a 0 latency mode)
[20:21] <BtbN> if you're live-streaming a game on your local PC, you want the lowest performance impact possible
[20:21] <Daemon404> yes
[20:22] <Daemon404> youre not from OBS by chance are you?
[20:23] <BtbN> i am
[20:24] <Daemon404> right. i shared a channel with another dude from OBS too.
[20:24] <Daemon404> (2 maybe?)
[20:32] <Skyler_> nvenc is the worst of all the main three hardware encoders I've tested
[20:32] <Skyler_> though I think it's faster than the AMD one, which counts for something
[20:33] <BtbN> it's not that bad
[20:33] <Daemon404> i would think messing with the gpu for encoding whilst also rendering the game would be a bad idea. though, it probably doesnt affect it due to having a special hw encoder path.
[20:34] <Skyler_> well, I re-tested it about two weeks ago or so and it was still pretty bad, and its VBV handling was atrocious, though only in low latency mode
[20:36] <BtbN> Daemon404, yes, the only performance impact it has is the bandwidth it uses
[20:40] <nevcairiel> I tried nvidias shadowplay feature, and the quality of the recording was quite bad. Might be partly because i played at 2560x1600 and it records at 1080p, maybe the scaling just sucks, but i was not impressed
[20:51] <J_Darnley> Wow!  Just discovered the "exec" command in git's interative rebase.
[20:51] <J_Darnley> *interactive
[20:53] <nevcairiel> how is that all that "Wow" worthy? not sure what i would really do with that :)
[20:53] <iive> oh no... he is going out of control. Now there is no way to stop him, he could do ANYTHING!!!
[20:54] <J_Darnley> You could have it run fate between each commit if you alrady made changes with rebase
[20:55] <nevcairiel> that sure would take a long time to rebase
[20:55] <J_Darnley> Or I can run this short test script in the right place to gather my data
[20:56] <J_Darnley> rather than running it manually by usding the "edit" command
[20:57] <iive> :)
[20:57] <cone-814> ffmpeg.git 03Alexandra Khirnova 07master:28e508a94677: dnxhddec: return proper error code
[20:57] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:8c596864cd95: Merge commit '28e508a94677d5dffde009c5f8ca7d6a4d2ca8e8'
[20:58] <J_Darnley> Doesn't fate let you run not-all-the-tests by specifying the right targets?
[20:58] <nevcairiel> it does
[20:59] <J_Darnley> You could do that rather than the all the tests each time
[20:59] <nevcairiel> i would probably rather let it finish rebase and test after, and bisect if need be. Yours sounds like you're expecting terrible failures each time :)
[21:43] <cone-814> ffmpeg.git 03Martin Storsjö 07master:d6eac2f1bcce: arm: Remove a stray .fpu directive
[21:43] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:b7c6ccc1e6a1: Merge commit 'd6eac2f1bcce0cb85fac5d50fcfe94bc490d4a5e'
[21:52] <superware> I'm pulling frames with av_read_frame from a live video source, should it be possible to display them as they are being pulled without any syncing and still get a smooth result?
[22:00] <BtbN> I uploaded a quality sample for nvenc vs. libx264: https://btbn.de/files/bbbunny_nvenc.mp4 and https://btbn.de/files/bbbunny_x264.mp4 nvenc preset was "high quality", x264 preset was veryfast, both at 3kbit/s. nvenc did ~100 fps, x264 ~50fps
[22:25] <Compn> BtbN : so you got it working? :)
[22:25] <BtbN> yes, it works fine. I just need to add more settings, currently it's all hardcoded except for a few basic things
[22:39] <iive> BtbN: did you check the actual quality?
[22:39] <BtbN> actual quality?
[22:44] <iive> PSNR, SSIN, visual inspection.
[23:43] <cone-814> ffmpeg.git 03Janne Grunau 07master:6a8475dc4f10: asvenc: free avctx->coded_frame on codec close
[23:43] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:682e289b979d: Merge commit '6a8475dc4f10d65edb7faa8df6e035af0ddcce19'
[00:00] --- Mon Feb 10 2014