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

[burek]

[01:12:26 CEST] <omerjerk> how do I set CONFIG_WINDOW=yes in config.mak file ?
[01:12:38 CEST] <omerjerk> looks like this file is automatically generated. 
[01:13:03 CEST] <omerjerk> what do I have to do to get this option added automatically ?
[01:13:12 CEST] <DHE> it is, configure produces it on unix systems
[01:13:46 CEST] <DHE> but I don't see a CONFIG_WINDOW option
[01:16:17 CEST] <omerjerk> there's one added by the encoder I'm working on.
[01:18:11 CEST] <omerjerk> so if there's an OBJS-$(CONFIG_WINDOW) += window.o in the Makefile, would it get added automatically to the config.mak file ?
[01:20:05 CEST] <DHE> no
[01:22:51 CEST] <omerjerk> then how is an option added to config.mak ?
[01:23:03 CEST] <jkqxz> What is "window"?  If it's a whole useful component like an encoder or filter or whatever then add it to the appropriate list file (like libavcodec/allcodecs.c), and then it will be picked up automatically by configure.  If it's some sort of subcomponent, then you need to add it to configure directly (under CONFIG_EXTRA, perhaps).
[01:24:30 CEST] <omerjerk> tbh, I don't know what's "window" here. 
[01:24:38 CEST] <omerjerk> let me send you the link
[01:25:56 CEST] <omerjerk> I'm working on someone else's source code to get it working with the latest ffmpeg sources.
[01:25:56 CEST] <omerjerk> https://github.com/justinruggles/FFmpeg-alsenc/blob/alsenc/libavcodec/Makefile#L45
[01:26:12 CEST] <omerjerk> here's where he has defined the CONFIG_WINDOW
[01:26:29 CEST] <omerjerk> so what do you suggest ?
[01:27:02 CEST] <jkqxz> You want <https://github.com/justinruggles/FFmpeg-alsenc/blob/alsenc/configure#L913>.
[01:27:51 CEST] <omerjerk> oh okay. thanks a lot. 
[01:28:52 CEST] <jkqxz> Though that has been split up.  It will work to put it there, but it probably goes better in one of the sublists (probably CONFIG_EXTRA?).
[01:32:07 CEST] <omerjerk> I'm not sure. I can move it if you say.
[01:35:11 CEST] <omerjerk> but this can be discussed later when I send the final patch to the mailing list, which will take a lot of time as of now.
[03:05:36 CEST] <cone-986> ffmpeg 03Rick Kern 07master:143685a42bbc: lavc/audiotoolboxenc: fix dropped frames on iOS
[03:24:11 CEST] <cone-986> ffmpeg 03Rick Kern 07master:8e47a99f576d: lavc/videotoolbox: fix H.264 hwaccel init issue
[03:24:12 CEST] <cone-986> ffmpeg 03Rick Kern 07master:2584299ae688: MAINTAINERS: Add myself for videotoolbox.c, remove vda* maintainer
[03:24:13 CEST] <cone-986> ffmpeg 03Rick Kern 07master:8b069b1cd516: lavc/videotoolboxenc: remove unnecessary logging
[06:52:56 CEST] <KGB> [13FFV1] 15dericed opened pull request #19: Make rfc format (06master...06make-rfc-format) 02https://git.io/vozkz
[08:11:22 CEST] <omerjerk> Hi
[08:11:34 CEST] <omerjerk> what would be the alternative of this code ? - https://github.com/justinruggles/FFmpeg-alsenc/blob/alsenc/libavcodec/x86/window.c#L25
[08:12:03 CEST] <omerjerk> mm_support() is to check for multimedia support on the current machine. 
[08:43:34 CEST] <cone-354> ffmpeg 03Steve Lhomme 07master:193a42199487: d3d11va: don't keep the context lock while waiting for a frame
[10:34:47 CEST] <ubitux> is kernrj on irc?
[10:35:22 CEST] <ubitux> (rick kern)
[11:10:57 CEST] <cone-354> ffmpeg 03Muhammad Faiz 07master:ee575acb8c8c: swresample/resample: add support for odd phase_count
[11:10:58 CEST] <cone-354> ffmpeg 03Muhammad Faiz 07master:7f1b503ec218: swresample/resample: do not increase phase_count on exact_rational
[11:35:53 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vozuE
[11:35:53 CEST] <KGB> 13FFV1/06master 14e28bb95 15Jérôme Martinez: Reformatting before SliceContent changes...
[12:55:10 CEST] <jsebechlebsky> Hi, is there a way I can calculate AVPacket duration in muxer, if duration field == 0?
[13:28:35 CEST] <flux> wait for the next frame and get its pts?
[16:12:53 CEST] <Zeranoe> I think I might switch over to using the native Windows zip archive for the builds
[16:13:16 CEST] <Zeranoe> the compression ratio is horrid but you don't need to download and install 7-zip
[16:15:17 CEST] <BBB> Zeranoe: that seems reasonable
[16:18:30 CEST] <Loriker> Zeranoe: yes, no 7-zip, please
[16:20:30 CEST] <Zeranoe> And I think I'll also change the filename from "ffmpeg-20160614-git-cb46b78-win64-static" to "ffmpeg-20160614-cb46b78-win64-static"
[16:36:48 CEST] <cone-058> ffmpeg 03Kongqun Yang 07master:54327c2b3449: Add experimental support for vp9 in iso-bmff
[16:49:36 CEST] <vade> hi - im using the new codecpar API, and im decoding a video stream with my own manually created codec context using avcodec_parameters_to_context from the codecpar on my target stream I want to be decoding. Codec par does not have a frame_rate struct entry, and intersringly, my streams->codec->framerate differs from my custom CodecContext->framerate - is this expected? Basically, I do something like avformat_alloc_context, 
[16:49:36 CEST] <vade> avformat_open_input, avformat_find_stream_info, av_find_best_stream. Then, I avcodec_alloc_context3 to make my own codec context, and assign avcodec_parameters_to_context from my best stream to my newly created context. at that point, avcodec_open2 and my streams codec vs my custom codec have some differing settings. Should I be opening my streams codec prior to avcodec_parameters_to_context ?
[16:55:03 CEST] <ubitux> rkern: any plan on making vt dec a decoder instead of an hwaccel?
[17:00:24 CEST] <rkern> yeah, unless someone else has dibs on it. It would be easier to use from the API that way.
[17:01:01 CEST] <ubitux> nice
[17:01:15 CEST] <nevcairiel> rcombs talked about that some time ago
[17:01:19 CEST] <ubitux> it might also help getting async api working
[17:03:45 CEST] <rkern> what's the issue with the async api?
[17:04:11 CEST] <rkern> I haven't used it with the hwaccel yet.
[17:06:51 CEST] <ubitux> it doesn't look possible to do with the current hwaccel api
[17:20:57 CEST] <BtbN> cuvid has a similar problem
[17:22:03 CEST] <ubitux> what was the reason for making an hwaccel instead of a decoder?
[17:24:36 CEST] <BtbN> For cuvid?
[17:24:54 CEST] <BtbN> Cuvid is a decoder (+ dummy hwaccel)
[17:28:43 CEST] <ubitux> ah, my bad, ok
[17:30:11 CEST] <vade> sorry to intterupt, - im curious if anyone has any input regarding the differences im seeing in a streams codec contexts time base, versus a codec context initialized with the same streams codecpar info - im trying to avoid warnings regarding poking at stream->codec and use the new API surrounding the codecpar 
[17:31:22 CEST] <nevcairiel> the timebase is largely irrelevant
[17:31:57 CEST] <vade> well, im just curious as to why the codecpar initialized codec differs from the streams is all. 
[17:32:07 CEST] <vade> streams->codec to be clear
[17:33:55 CEST] <BBB> michaelni: would you expect ffv1 to be 5-10x as slow (in decoding) as a compressed version of the same file in a modern codec (e.g. vp9 or hevc)?
[17:34:15 CEST] <BBB> michaelni: and if the answer is yes, is that just symbol decoding? or do you think theres opportunity to optimize some of that?
[17:34:29 CEST] <BBB> (or maybe symbol decoding can be optimized, dunno)
[17:36:23 CEST] <michaelni> BBB i wouldnt expect it to be that slow
[17:36:53 CEST] <BtbN> ubitux, the problem with cuvid is that making it an hwaccel would add some features the ffmpeg h264 parser has. Like, closed caption support.
[17:37:05 CEST] <BBB> my system has huge issues decoding a ffv1 file (encoded by myself), its basically using all 4 cores just for the ffv1 decoding in more active scenes
[17:37:31 CEST] <BBB> are there things I need to do beyond just -c:v ffv1 in the encoder to get best ffv1 decoding performance?
[17:37:47 CEST] <BtbN> But as a CUDA Frame just contains a Device Pointer, it would be neccesary to pull it from the decoder immediately. But cuvid gets horribly slow if you don't delay frame output by a few frames
[17:37:53 CEST] <BBB> (the content is 1080p but my laptop isnt that old)
[17:38:23 CEST] <BtbN> So it's now using the cuvid parsers, missing out on some features.
[17:38:38 CEST] <atomnuker> BBB: did you enable range coding?
[17:39:15 CEST] <BBB> I literally did ffmpeg -i file.y4m -c:v ffv1 -an file.mkv
[17:40:17 CEST] <BBB> is there some doc that explains how to best use this encoder? I mean, I dont even know if it uses particular compression features or not
[17:41:27 CEST] <ubitux> doc with ffv1 would be very welcome yes
[17:41:30 CEST] <BBB> I feel the wiki should not jsut explain what settings exist, but also what defaults should be used for particular use cases
[17:41:45 CEST] <ubitux> i remember huge performance differences according to the dimension of the video
[17:41:46 CEST] <BBB> like, it seems like -g 1 is default, which seems like a terrible idea
[17:41:47 CEST] <michaelni> someone should write something i guess, some benchmatks are at (agaist huffyuv) http://guru.multimedia.cx/ffmpegs-huffyuv/
[17:41:52 CEST] <ubitux> because it was enabling or disabling features
[17:42:17 CEST] <atomnuker> -level 4 -coder range_tab gives you the best compression
[17:42:33 CEST] <BBB> michaelni: what are recommended settings if my purpose is just to input the ffv1 file into an encoder?
[17:42:41 CEST] <BBB> should I change default for -g?
[17:42:48 CEST] <atomnuker> (though -level 4 enables version 2 which is experimental)
[17:43:40 CEST] <BBB> what are defaults for all settings?
[17:46:42 CEST] <michaelni> it uses the small context and the rice coder by default 
[17:46:59 CEST] <BBB> would you recommend using large contexts (-context 1)?
[17:47:22 CEST] <michaelni> yes unless its slower by a too big amount
[17:47:33 CEST] <michaelni> i didnt recently benchmark and test things
[17:48:17 CEST] <ubitux> michaelni: about #631 fate test, any better suggestion than -max_error_rate 0.95?
[17:48:36 CEST] <BBB> maybe I should go back to huffyuv...
[17:48:42 CEST] <BBB> but then again, huffyuv...
[17:48:58 CEST] <BBB> let me compare a little
[17:51:36 CEST] <jamrial> BBB: try also x264 lossless. last time i checked it had the best compression ratio, but didn't bechmark decoding speed
[17:52:47 CEST] <atomnuker> jamrial: a week ago I benchmarked that on some very hard to encode content, ffv1 won in terms of efficiency
[17:53:53 CEST] <BBB> jamrial: thats probably worth trying, Ill test that, thanks
[17:54:33 CEST] <ubitux> x264 with qp=0 is much faster iirc
[17:55:07 CEST] <michaelni> it would be interrestig to find out why ffv1 is so much slower
[17:55:11 CEST] <michaelni> if it is
[17:56:45 CEST] <michaelni> ubitux, about 631, i dont see a better solution, so its ok
[17:57:01 CEST] <ubitux> ok
[17:57:21 CEST] <ubitux> my bad, libx264/qp0 looks slower after a quick test
[17:57:27 CEST] <ubitux> (encode speed)
[17:58:00 CEST] <BBB> Im not very familiar with how ffv1 works, but all decode time seems to be spent in decode_plane (24.9%) and in symbol decoding (ur_golomb, vlc_symbol, get_context, update_vlc_state, sr_golomb, get_bits, get_bits1 - totaling 44.6 of runtime in this app) more so than in reconstruction (predict, mid_pred - totaling 10.2%)
[17:58:23 CEST] <BBB> I dont know what decode_plane does exactly
[18:00:18 CEST] <michaelni> ffv1 is not really complex, just predict samlple, find context from surrounding samples, store difference
[18:00:44 CEST] <michaelni> http://www.ffmpeg.org/%7Emichael/ffv1.html
[18:00:57 CEST] <ubitux> BBB: did you try utvideo?
[18:01:04 CEST] <BBB> nope
[18:01:12 CEST] <BBB> ffv1 seemed appropriate since its a standard
[18:01:32 CEST] <ubitux> utvideo encoder is 4x faster than ffv1 here
[18:02:27 CEST] <ubitux> 2.25x faster than ffv1 for 1080p though (previous sentence was 480p)
[18:03:51 CEST] <BBB> what about decoding?
[18:07:40 CEST] <ubitux> testsrc2 1080p 2min / utvideo: encode=172fps decode=160fps size=713M / ffv1: encode=80fps decode=91fps size=115M
[18:07:45 CEST] <ubitux> (no encode options for both)
[18:08:05 CEST] <ubitux> utvideo doesn't compress much apparently by default
[18:08:29 CEST] <michaelni> ffv1 probably would prefer a -slices <cpu core number> or something
[18:10:07 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:2770e16d700e: fate/h264: add test for ticket #631
[18:10:08 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:6fd58eba1cd1: lavc/videotoolbox: CFRelease() session
[18:10:09 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:6cb550e9331e: lavc/videotoolbox: remove config_info maximum capacity
[18:17:02 CEST] <michaelni> i get fps=177 for encode,  fps=285 for decode with -slices 12 and testsrc2=1920x1080 to ffv1
[18:18:59 CEST] <michaelni> interrestingly slices 24 gets fps=180/297 even though the box has just 12 logical cores
[18:21:02 CEST] <michaelni> ubitux, btw tested 631 on mips & mingw, worked fine
[18:28:30 CEST] <jamrial> quick test on a 4 core haswell, -slice 4: ffv1 encoding 116 fps decoding 127 fps, x264 qp 0 default preset and tune encoding 43 fps decoding 257 fps
[18:29:02 CEST] <jamrial> the x264 output was a bit smaller
[18:29:42 CEST] <jamrial> also used testsrc2 1080p
[18:30:15 CEST] <michaelni> ffv1 probably should use the range coder and large context if you want best compression
[18:38:52 CEST] <michaelni> actually with the simple testsrc input the more complex context and coder seem not to do much good
[18:40:19 CEST] <BtbN> It's possible to decode h264 at a lower resolution? (regarding that ml post)
[18:42:06 CEST] <nevcairiel> We should discourage any thought of such crap
[18:42:41 CEST] <jkqxz> You could do it for intra-only.  (That probably isn't what the sender wants, though.)
[18:43:09 CEST] <nevcairiel> lowres is a fragile anti-feature, should really not get any more of that
[18:43:10 CEST] <BtbN> I didn't even think it was possible to decode a lower resolution image from it
[18:43:13 CEST] <michaelni> 2pass ffv1 with range coder  and large context beats the other options for testsrc2
[18:43:31 CEST] <michaelni> other ffv1 options that is compression wise
[18:45:57 CEST] <michaelni> ./ffmpeg -f lavfi -i testsrc2=1920x1080  -vcodec ffv1 -t 30 -slices 12 -context 1  -coder 2  -y -pass 1/2 test12-c1-2.avi
[18:49:13 CEST] <jkqxz> nevcairiel:  Yeah, it would be horrible and shouldn't be merged.  But if someone wants to pay for it to be done for them, it would I think be possible to make work in a suitably limited case.
[18:59:42 CEST] <michaelni> jkqxz, as you are maintainer you should have op here
[19:00:42 CEST] <michaelni> anyone else who is maintainer AND properly signed in with freenode who doesnt have op ?
[19:06:46 CEST] <rcombs> ubitux: rkern: nevcairiel: I have a patch laying around for that; the biggest problem is that it doesn't do reordering internally, and so currently relies on container timestamps
[19:06:58 CEST] <rcombs> (VT as a dec instead of a hwaccel)
[19:07:16 CEST] <rcombs> I'll need to add some parsing to get it to work on streams without (valid) timestamps
[19:07:48 CEST] <rcombs> michaelni: people have told me that I should add myself to maintainers for& I guess audiotoolbox?
[19:08:39 CEST] <nevcairiel> manually reordering h264 and hevc is evil
[19:08:58 CEST] <nevcairiel> and if the api cant do that for you, it really should be a hwaccel so the h264/hevc decoder can do the work for you
[19:09:17 CEST] <michaelni> rcombs, please add yourself to anything that you want to maintain and that isnt maintained
[19:09:57 CEST] <iive> BtbN: you can always decode only DC coefficients. make idct a lot simpler :D
[19:10:00 CEST] <michaelni> once you are in maintiners ill add you to the op list
[19:10:36 CEST] <rcombs> nevcairiel: the crazy thing is that there's a flag pin the VT API that _allows_ it to reorder internally& and it doesn't actually do anything (in my testing)
[19:12:01 CEST] <iive> michaelni: why is ffv1 decoding so much slower than h264? they both use cabac and ffv1 doesn't even have loopfilter.
[19:13:37 CEST] <michaelni> iive, h264 is bit simpler on the decoder side and people spend more time optimizng the h264 code i think (this is mostly guessing, it would require more work to find a definite awnser)
[19:13:44 CEST] <michaelni> also no loopfilter with lossless
[19:14:18 CEST] <iive> oh, 264 lossless, of course.
[19:15:18 CEST] <rkern> rcombs: sounds good. I can test it out when you're done.
[19:15:29 CEST] <iive> last time i looked at ffv1 i remember that it worked on 16bit samples, that are then cut to 8 bit. since the only operation was addition, it could be done entirely on 8 bits
[19:15:56 CEST] <rkern> rcombs: +1 for adding yourself as audiotoolbox maintainer
[19:16:39 CEST] <rcombs> rkern: https://gist.github.com/e32779b8da641f54a33b040d77b73a46 here's what I've got now (not complete)
[19:18:01 CEST] <michaelni> rkern, do you have a freenode account ? i dont see a "logged in" in /whois
[19:30:14 CEST] <rkern> michaelni: I don't think so. I'll get that set up in a little bit.
[19:31:40 CEST] <ubitux> rcombs: reordering is easy to do
[19:31:49 CEST] <ubitux> with vt at least
[19:37:04 CEST] <BBB> michaelni: no please dont (h264 lowres)
[19:37:10 CEST] <BBB> michaelni: it will be beyond hideously ugly
[19:37:15 CEST] <BBB> michaelni: it has no place in our coebase
[19:37:38 CEST] <BBB> michaelni: just tell him to use mpeg or so
[19:38:45 CEST] <ubitux> we were considering using lowres as well
[19:38:54 CEST] <ubitux> for that exact same purpose
[19:39:19 CEST] <ubitux> BBB: you rarely control the user input :p
[19:40:31 CEST] <BBB> we?
[19:43:22 CEST] <iive> hum, i thought that h264 had lowres, but it have been removed.
[19:52:14 CEST] <rkern> michaelni: yeah I wasn't registered... it's setup now.
[20:06:32 CEST] <michaelni> rkern, ok added you to the acces list
[20:07:11 CEST] <michaelni> BBB lowres with h264 is hard anyway as intra pred would smear artefacts over the image
[20:13:40 CEST] <BBB> michaelni: does ffv1 have p frame support?
[20:18:52 CEST] <michaelni> BBB, stanislav dolganov is working on "FFv1 P frame support" this years GSoC., if you have ideas or comments to him that would be very welcome
[20:29:57 CEST] <ubitux> BBB: my company, sorry
[20:30:26 CEST] <BBB> I didnt know you started a company - congrats!
[20:33:49 CEST] <ubitux> BBB: i didn't
[20:33:54 CEST] <ubitux> "the company i work for"
[20:34:00 CEST] <ubitux> damn languages
[21:51:43 CEST] <cone-858> ffmpeg 03Michael Niedermayer 07master:737f06577ca9: avcodec/snow: Remove unused function
[21:51:43 CEST] <cone-858> ffmpeg 03Michael Niedermayer 07master:4efbeadadc6f: avcodec/snow: Document BlockNode
[21:55:47 CEST] <cone-858> ffmpeg 03James Almer 07master:403a53c60e7c: avcodec/ffv1enc: silence warning about deprecated coded_frame
[22:58:04 CEST] <ubitux> http://b.pkh.me/rebase-merge.txt
[22:58:19 CEST] <ubitux> next time someone feels like doing some nasty rebase of a merge
[00:00:00 CEST] --- Sat Jun 18 2016