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

burek burek021 at gmail.com
Mon Jul 27 02:05:02 CEST 2015


[00:00:33 CEST] <nevcairiel> I had the same feeling when I was working on decoding at some point
[00:00:43 CEST] <nevcairiel> just delaying access to the frame and it becomes much faster
[00:02:40 CEST] <BtbN> hm, can't think of a good name for that parameter
[00:02:48 CEST] <nevcairiel> delay
[00:03:38 CEST] <BtbN> hm, yeah
[00:04:29 CEST] <philipl> nevcairiel: aren't the decoders conceptually stateless?
[00:05:13 CEST] <nevcairiel> from the API sure, but if you access the frame too early you probably enforce an internal sync of some sort, which blocks the parallelism
[00:06:12 CEST] <philipl> a fair point
[00:06:14 CEST] <nevcairiel> basically, you get a frame handle back for the resulting frame, but the decoder is still working on it, so if you delay it 1-2 frames... more speed
[00:06:30 CEST] <philipl> Yes, makes sense. Basic pipelining
[00:07:07 CEST] <nevcairiel> i read some tips from nvidia on that, they basically explained it with decoding being in multiple stages, and if you do it that way, you can have different frames in the different stages
[00:07:15 CEST] <nevcairiel> which makes sense
[00:07:20 CEST] <philipl> fur sure.
[00:07:46 CEST] <cone-201> ffmpeg 03Paul B Mahol 07master:c1fa846d0c23: avfilter: add sidechain compress audio filter
[00:07:47 CEST] <cone-201> ffmpeg 03Paul B Mahol 07master:62aab839f805: avfilter/Makefile: fix order of framestep filter
[00:07:52 CEST] <nevcairiel> encoding probably works similar
[00:08:03 CEST] <nevcairiel> so keeping a buffer before accessing the result makes it faster
[00:08:27 CEST] <philipl> Yeah.
[00:21:57 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commit/a67f9ac874495a616f9d88a9b266e0ec8ccff1a8 
[00:22:45 CEST] <philipl> BtbN: default to 0?
[00:23:02 CEST] <BtbN> that'd be the old slow behaviour
[00:23:30 CEST] <philipl> Sure, but you want to keep that as the default?
[00:24:05 CEST] <BtbN> I think it makes more sense this way around
[00:24:26 CEST] <BtbN> propably also puts less stress on the hardware
[00:25:17 CEST] <BtbN> Nobody would ever add some delay, people only want less delay.
[00:25:32 CEST] <BtbN> So having it in the fast mode by default seems better
[00:26:27 CEST] <philipl> BtbN: Hmm.
[00:26:34 CEST] <philipl> The default doesn't seem to acting as if its zero
[00:26:46 CEST] <BtbN> hm?
[00:26:50 CEST] <philipl> I'm confused.
[00:26:54 CEST] <nevcairiel> the default is INT_MAX
[00:26:57 CEST] <nevcairiel> it says so
[00:27:04 CEST] <philipl> oh, sorry. I read it wrong.
[00:27:11 CEST] <philipl> That's why I was confused.
[00:27:18 CEST] <philipl> I thought you defaulted it to zero
[00:27:44 CEST] <philipl> No wonder we were both so confused.
[00:30:09 CEST] <BtbN> I'll do some testing with it myself, but i think this should be fine, if you have no objections, i'll push it once i'm done.
[00:30:20 CEST] <philipl> Looks good to me, works as advertised.
[00:33:26 CEST] <philipl> BtbN: From a quick check, I think the hardware is happy once the delay is at least 3 frames.
[00:33:34 CEST] <cone-201> ffmpeg 03Anton Khirnov 07master:96dca089b19b: qsvdec: move qsv_process_data() from qsvdec_h264 to the common code
[00:33:35 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:a822c3bd7974: Merge commit '96dca089b19bf55293136277f5b081c56146e10e'
[00:36:27 CEST] <philipl> nvidia-settings has a video engine utilization percentage these days. With delay 0 it says 22% for my example, and with max delay it's 77%
[00:41:57 CEST] <BtbN> philipl, even with my kepler card, transcoding a simple test clip, 1080p, i get 60 fps with -delay 0, and 90 without
[00:42:04 CEST] <BtbN> (all nvenc settings on default)
[00:42:43 CEST] <cone-201> ffmpeg 03Anton Khirnov 07master:f89f78c1c563: lavc: add a HEVC mp4->annex B bitstream filter
[00:42:45 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:15bcbc9d3b88: Merge commit 'f89f78c1c563d98f10ee1d7e1ed67c9f9e03b741'
[00:43:05 CEST] <durandal_1707> libav bugtracker forbids to peek at crashes how neat...
[00:44:19 CEST] <BtbN> what?
[00:50:06 CEST] <kierank> durandal_1707: huh?
[00:50:57 CEST] <philipl> BtbN: And I got 99% utilization from a 4k encode.
[00:52:34 CEST] <durandal_1707> kierank: it even doesn't list it I guess one need to register
[00:54:13 CEST] <durandal_1707> this .needs_fifo sucks for audio when 2nd stream reaches eof
[00:56:08 CEST] <durandal_1707> and using fifo directly is pita because one needs to allocate frame to read samples
[01:00:04 CEST] <cone-201> ffmpeg 03Timo Rothenpieler 07master:9f4bff834c47: avcodec/nvenc: Delay frame output to increase encoding speed
[01:05:03 CEST] <philipl> managed to crash my nvidia driver with all my tests :-)
[01:06:02 CEST] <philipl> nevcairiel: did you ever establish whether your ucNumDeltaPocsOfRefRpsIdx fix was needed?
[01:07:26 CEST] <cone-201> ffmpeg 03Anton Khirnov 07master:bf52f773913c: lavc: add Intel libmfx-based MPEG2 decoder.
[01:07:27 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:bb619f41bea8: Merge commit 'bf52f773913cf74bdf0d2c8c2cb4473fa1b7801e'
[01:09:12 CEST] <BtbN> Is that the one from libav? So, there are two now?
[01:15:58 CEST] <philipl> weeeeeeeeeeeeeeeeeeeeeeeeeee
[01:17:22 CEST] <wm4> business as usual
[01:20:05 CEST] <BtbN> philipl, also getting 99% utilization with 1080p at ~90 fps now
[01:35:35 CEST] <cone-201> ffmpeg 03Anton Khirnov 07master:41d47ea85fb4: lavc: add Intel libmfx-based HEVC decoder.
[01:35:36 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:508b79e6c1dc: Merge commit '41d47ea85fb4ad9cfb5c2dc808a46bc1d57f3986'
[01:56:07 CEST] <ckh_> Hey guys. I saw your post that you need hosting / server space. I'd like to help (and the higher ups said okay). I'm colleen from Facebook. You can hit me up at ckh at fb.com 
[01:57:52 CEST] <BtbN> There's currently a discussion ongoing on the ffmpeg-devel mailing list, about choosing the new host, it's propably best to post there
[01:58:31 CEST] <BtbN> More options are definitely still welcome, the current host was kinda rushed because stuff had to move fast
[02:00:39 CEST] <ckh_> Ah. But they currently have options? Thats good news :)
[02:01:10 CEST] <BtbN> Yes, a few people offered sponsored or free hosting options
[02:01:56 CEST] <ckh_> Ah. I suggested internally that we foot the bill for you guys to use EC2, GCE, whatever. 
[02:02:42 CEST] <ckh_> I gotta run to an airport. Ill check out the mailing list at some point. Thanks :)
[02:04:16 CEST] <cone-201> ffmpeg 03Ivan Uskov 07master:1defff85cb2c: libavcodec/h264_mp4toannexb_bsf.c: Optional argument "private_spspps_buf" to avoid extradata modification.
[02:16:32 CEST] <cone-201> ffmpeg 03Ivan Uskov 07master:684b7038436f: libavcodec/qsvdec_h264.c: using "private_spspps_buf" argument for av_bitstream_filter_filter() to avoid failure after decoder re-initialization.
[02:31:14 CEST] <jamrial> BtbN: no, not two fortunately this time :p
[02:31:23 CEST] <jamrial> libav's was basically not merget at all
[04:16:55 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:e01153839451: avformat/ipmovie: Factor init_audio() out
[04:16:56 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:8e0fdb03a2f1: avformat/ipmovie: Parse&handle late audio init
[04:16:57 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:c3361b3a8786: avformat/ipmovie: Fix late audio detection
[05:40:58 CEST] <cone-201> ffmpeg 03James Almer 07master:ec7f04c13a6e: avcodec/texturedsp: fix undefined shift
[06:00:15 CEST] <cone-201> ffmpeg 03Anshul Maheshwari 07master:379ddc6af44f: avformat/hlsenc: Add WebVtt support in hls
[07:51:54 CEST] <cone-201> ffmpeg 03James Almer 07master:844bef578ee0: avcodec/x86: add missing colon to labels
[07:51:55 CEST] <cone-201> ffmpeg 03James Almer 07master:d9e10af54784: x86/vf_interlace: add missing colon to labels
[07:51:56 CEST] <cone-201> ffmpeg 03James Almer 07master:4d2c014a8f0a: x86/float_dsp: add missing colon to labels
[07:51:57 CEST] <cone-201> ffmpeg 03James Almer 07master:f37a5dcb55d1: swresample/x86: add missing colon to labels
[10:01:57 CEST] <nevcairiel> philipl: that fix is definitely needed for dxva2, but apparently for nothing in fate
[11:21:02 CEST] <nevcairiel> philipl: as in, i can definitely still reproduce failure on my GTX960 without it on a certain sample
[11:21:13 CEST] <nevcairiel> (just tried again this minute to make sure)
[12:04:40 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:4d0d55cd623b: checkasm: Use LOCAL_ALIGNED
[12:04:41 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:ce466275f8d6: Merge commit '4d0d55cd623bcd504867f948849380f6b4060b4d'
[13:57:17 CEST] <durandal_1707> have someone also been contacted by some gif guys?
[13:57:35 CEST] <BtbN> gif guys?
[13:57:58 CEST] <Daemon404> is that some sort of perverted cult
[13:59:08 CEST] <durandal_1707> folks that create gifs for you to enjoy
[13:59:55 CEST] <BtbN> Aren't those sites now using mp4 videos anyway?
[14:00:12 CEST] <BtbN> even though they invented the new format gifv for it
[14:00:20 CEST] <BtbN> (which is mp4 with a diffrent file extension)
[14:04:00 CEST] <ubitux> isn't it webm?
[14:04:37 CEST] <BtbN> also possible, but it's just something common with their own file extension
[14:06:27 CEST] <Daemon404> it's both
[14:06:31 CEST] <Daemon404> it serves it depending on browser
[14:06:49 CEST] <Daemon404> 'gifv' is to make it easier for normal people to understand
[14:07:32 CEST] <durandal_1707> "normal"
[14:07:50 CEST] <phh> ubitux: ^^^
[14:08:46 CEST] <ubitux> :(
[14:08:59 CEST] <ubitux> durandal_1707: anyway yeah i've been contacted as well
[14:16:08 CEST] <Compn> durandal_1707 : are the gif people asking you for favors or job offers?
[14:17:26 CEST] <durandal_1707> they are asking to ban Compn from this channel :/
[14:18:42 CEST] <wm4> lol
[14:41:09 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:4b90dcb84935: avcodec/dvbsubdec: Compute default CLUT based on bitmap analysis
[15:07:13 CEST] <BBB> durandal_1707: who is they?
[15:09:25 CEST] <durandal_1707> nobody wants ban that was joke
[15:09:56 CEST] <BBB> oh ok
[16:15:00 CEST] <michaelni> philipl, BtbN, theres a nvenc pull req https://github.com/FFmpeg/FFmpeg/pull/140
[16:15:26 CEST] <michaelni> just saw it
[16:16:10 CEST] <michaelni> can you review? should i apply/merge it ?
[16:19:46 CEST] <wm4> close it and say patches go to the mailing list
[16:20:29 CEST] <BtbN> This PR looks strange. While he is right that "2Pass" supports seems to have improved, i'm not sure of the way he implements that.
[16:21:15 CEST] <nevcairiel> judging from the commit in the PR, it was never explicitly forbidden in the code
[16:21:18 CEST] <BtbN> if i'm not mistaken, 2Pass mode allways worked with all presets, and only displayes a warning
[16:21:19 CEST] <nevcairiel> just issued a warning message
[16:21:28 CEST] <BtbN> exactly
[16:21:29 CEST] <nevcairiel> which makes his commit way too complex
[16:21:35 CEST] <nevcairiel> just remove the warning and voila
[16:31:40 CEST] <BtbN> his commit even breaks the twopass tristate option
[17:29:59 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:e0031ca29a47: avcodec/avrndec: Fix cropping
[17:44:04 CEST] <cone-084> ffmpeg 03WereCatf 07master:7106dfd94568: avcodec/nvenc: 2-pass mode works even with non-low latency presets now
[17:46:29 CEST] <j-b> WereCatf?
[17:51:41 CEST] <BtbN> guy on github
[17:52:18 CEST] <BtbN> michaelni, the PR should have auto-closed once the commit reached github
[18:04:01 CEST] <liquidee> hello everyone. Has anyone ever used av_format_control_message? I am trying to implement a way to send control messages to devices like xv to control their behaviour. Is it possible to get AVFormatContext of the specific device inside a filter?
[18:04:17 CEST] <michaelni> BtbN, ohh ok didnt realize
[18:04:49 CEST] <liquidee> Just looking for a clear and proper way to implement this
[18:13:09 CEST] <durandal_1707> ubitux: is nlmeans filter going to have temporal option?
[18:21:22 CEST] <ubitux> durandal_1707: i read papers, and they were saying it was pointless, so i didn't plan to
[18:26:28 CEST] <ubitux> should i?
[18:56:55 CEST] <philipl> nevcairiel: Hmm. I've played around with and without your patch and the Sintel file you said showed the problem but I never saw any difference in vdpau
[19:06:59 CEST] <cone-084> ffmpeg 03Niklesh 07master:f21fcf60eca9: movtextdec.c: Add support for fontsize
[21:42:51 CEST] <BBB> does anyone here think we should just rewrite ffplay in straight opengl?
[21:43:03 CEST] <BBB> (random idea; probably far-fetched)
[21:45:57 CEST] <BtbN> dealing with opengl context creation on all platforms? Nah
[22:05:21 CEST] <nevcairiel> there is light-weight libs for that
[22:05:28 CEST] <nevcairiel> more light-weight than sdl 
[22:05:39 CEST] <nevcairiel> the added problem is audio then
[22:06:17 CEST] <BtbN> aren't there audio output filters for almost everything already?
[22:14:08 CEST] <wm4> doesn't libavdevice have opengl support?
[22:14:55 CEST] <wm4> but seriously, using a muxer API for video output
[22:15:07 CEST] <wm4> this shit should just be removed and replaced by a proper API
[22:17:06 CEST] <cone-084> ffmpeg 03Steve Lhomme 07master:c5327df83839: force WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP to use DVXA
[22:17:07 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:29a43bd588b0: avformat/hlsenc: Fix wording in comment
[22:39:08 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:dc07e576ce72: avformat/isom: Use AVRN codec to handle AVDJ
[22:43:09 CEST] <durandal_1707> wm4: with one from libmpv?
[22:43:54 CEST] <wm4> durandal_1707: no, libmpv doesn't have a video output API
[22:44:08 CEST] <wm4> and mpv's internal one isn't that great either
[22:44:29 CEST] <wm4> just go design something reasonable instead of coercing it into a muxing API or whatever
[22:45:30 CEST] <durandal_1707> can't because awaiting libav
[22:47:04 CEST] <wm4> ?
[22:54:16 CEST] <cone-084> ffmpeg 03Steve Lhomme 07master:9b4b96c0dee9: force WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP to be able to use dxva.h
[22:54:17 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:508c815d4db0: Merge commit '9b4b96c0dee90d260891ec765b28f6ca15594340'
[23:04:12 CEST] <kierank> libav was going to merge it into libavformat
[23:18:35 CEST] <cone-084> ffmpeg 03Martin Storsjö 07master:0cff125200ab: configure: Only add -FIstdlib.h for msvc/icl if necessary
[23:18:36 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:867686997cba: Merge commit '0cff125200ab53fa3ae70d85b4f614f269fe3426'
[23:30:23 CEST] <cone-084> ffmpeg 03Martin Storsjö 07master:5fd553d31272: configure: Only redefine inline to __inline for msvc if necessary
[23:30:24 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:27e61a716c89: Merge commit '5fd553d31272d5ed42a7a5a0ecaab7b3452da83a'
[23:57:50 CEST] <cone-084> ffmpeg 03Martin Storsjö 07master:342b0ba5f93b: configure: Only redirect strtoll to _strtoi64 if necessary
[23:57:51 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:dcc540db6ee0: Merge commit '342b0ba5f93b09b1d0c2597db44605300e6fcc53'
[00:00:00 CEST] --- Mon Jul 27 2015


More information about the Ffmpeg-devel-irc mailing list