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

[burek]

[00:15:28 CEST] <cone-339> ffmpeg 03Ganesh Ajjanagadde 07master:11b563ed8f7c: avcodec/motion_est_template: fix undefined left shift of negative number
[00:28:00 CEST] <cone-339> ffmpeg 03Hendrik Leppkes 07master:0118158efa8e: hevc: properly handle no_rasl_output_flag when removing pictures from the DPB
[00:28:39 CEST] <cone-339> ffmpeg 03Hendrik Leppkes 07release/2.8:41aa6b209585: hevc: properly handle no_rasl_output_flag when removing pictures from the DPB
[00:44:37 CEST] <philipl> BtbN: if you've got mpv, what more do you need? :-)
[00:45:11 CEST] <nevcairiel> clearly he is a avid gst user
[00:45:21 CEST] <philipl> hehe.
[00:48:05 CEST] <fritsch> nevcairiel: thx for push
[01:13:05 CEST] <cone-339> ffmpeg 03Ganesh Ajjanagadde 07master:094a1985d618: avcodec/mlpdec: fix a undefined left shift of negative number
[01:27:39 CEST] <cone-339> ffmpeg 03Ganesh Ajjanagadde 07master:7cf22c79706d: swscale/output: fix undefined left shifts of negative numbers
[02:27:18 CEST] <kylophone> FFmpeg style guide says to watch out for `mixing statements and declarations,' but I'm seeing this rule broken in a lot of code. Should this rule be followed for new patches?
[03:16:43 CEST] <cone-339> ffmpeg 03Ganesh Ajjanagadde 07master:6ea457f76d97: avformat/format: silence -Wdiscarded-qualifiers
[04:23:26 CEST] <cone-339> ffmpeg 03Ganesh Ajjanagadde 07master:92fabca427ff: avcodec/x86/hpeldsp_rnd_template: silence -Wunused-function on --disable-mmx
[05:56:23 CEST] <cone-339> ffmpeg 03James Almer 07master:784792788b9b: checkasm: add jpeg2000dsp rct_int tests
[11:03:31 CEST] <cone-756> ffmpeg 03Ronald S. Bultje 07master:b074367405ca: checkasm: add VP9 loopfilter tests.
[11:47:08 CEST] <cone-756> ffmpeg 03Michael Niedermayer 07master:bddcf758d3a6: tests/checkasm/vp9dsp: Add () to protect macro arguments
[13:06:22 CEST] <cone-756> ffmpeg 03Michael Niedermayer 07master:b947ac9096e3: avcodec/internal: Use do {} while() for ff_tlog()
[13:07:22 CEST] <xdbx> <xdbx> hey guys... any idea why ffmpeg depends on smbclient ?
[13:07:22 CEST] <xdbx> <xdbx> doesnt make sense for me 
[13:07:45 CEST] <xdbx> cant get it to configure cuz of that
[13:11:03 CEST] <xdbx> anyone here ?
[13:21:06 CEST] <fritsch> xdbx: you are in the wrong channel ... use --disable-libsmbclient
[13:22:42 CEST] <xdbx> ok, sorry
[13:22:52 CEST] <xdbx> thx for info thou
[13:24:23 CEST] <nevcairiel> libsmbclient should be disabled by default however, so you must have explicitly asked for that in the configure line
[13:25:50 CEST] <fritsch> nevcairiel: we are preparing the letter to intel
[13:25:56 CEST] <fritsch> nevcairiel: will have you and timo on cc
[13:26:18 CEST] <fritsch> concerning the 10 bit support on linux
[14:59:35 CEST] <rcombs> so, async lavc API
[14:59:49 CEST] <rcombs> how's this supposed to work
[15:00:42 CEST] <iive> i have bad feeling about it...
[15:01:12 CEST] <rcombs> passing a callback and calling it on a thread? or an API function to get an <output> if available, independently of sending an <input>?
[15:01:35 CEST] <rcombs> (where <input>/<output> are frames/packets or vice versa)
[15:04:40 CEST] <rcombs> and then maybe lavc/utils should provide threading wrappers for simple single-threaded codecs
[15:11:11 CEST] <iive> rcombs: all these sound bad to me.
[15:11:31 CEST] <iive> calling callbacks from unknown threads... this sound like can of worms...
[15:11:37 CEST] <rcombs> yeah, it does
[15:11:53 CEST] <rcombs> what've you got, then?
[15:13:19 CEST] <iive> the current api is already threaded.
[15:13:54 CEST] <iive> it allows consuming packets without having to produce frame and collecting frames without pushing packets.
[15:15:46 CEST] <iive> and if you want callbacks, check draw_horiz_band() 
[15:16:31 CEST] <nevcairiel> Submit and retrieve should just be independent calls
[15:16:57 CEST] <wm4> iive: see mmaldec.c what you actually have to do to connect a sync to an async API
[15:16:58 CEST] <nevcairiel> That way you could extend that to be proper threaded async if you wanted
[15:17:15 CEST] <wm4> iive: and similar things are AFAIK duplicated in qsv and vda/videotoolbox code
[15:17:32 CEST] <nevcairiel> But its usually easier to just do it all on one worker thread
[15:18:04 CEST] <rcombs> wm4: so is it just that the queueing and such currently need to be duplicated everywhere, and it'd be more efficient to factor that out into utils?
[15:18:31 CEST] <wm4> I think the main point is that there should be a m:n API, like nevcairiel already hinted
[15:19:03 CEST] <rcombs> wm4: the impression I'm getting from iive is that the current API is _supposed_ to support that in theory, and it's just messy?
[15:19:06 CEST] <wm4> (this could essentially be made asynchronous by adding notification callbacks)
[15:19:13 CEST] <wm4> rcombs: no, it doesn't
[15:19:19 CEST] <nevcairiel> It doesn't though
[15:19:36 CEST] <wm4> the current API can emulate independent packet/frame passing by adding a fixed "delay"
[15:19:44 CEST] <nevcairiel> It only supports m:1
[15:19:45 CEST] <wm4> this is how the multithreaded frame decoding support works
[15:19:45 CEST] <rcombs> nevcairiel: I'm thinking that lavc should handle creating worker threads for codecs that don't have any complex threading
[15:20:25 CEST] <nevcairiel> You could easily do that when you have an api like we are suggesting
[15:20:29 CEST] <rcombs> yeah
[15:21:07 CEST] <rcombs> so currently, you can't get multiple <outputs> out of a codec by passing NULL <inputs>, then?
[15:21:13 CEST] <nevcairiel> No
[15:21:20 CEST] <nevcairiel> Only at EOF
[15:21:22 CEST] <wm4> here are some minor suggestions https://wiki.libav.org/Blueprint/DecoupledCodecAPI
[15:22:05 CEST] <nevcairiel> Half of those apis suggested there are useless though
[15:22:14 CEST] <nevcairiel> You really only need submit and retrieve
[15:22:55 CEST] <rcombs> nevcairiel: well, it could be useful to have a retrieve function that doesn't block if nothing's available
[15:23:05 CEST] <wm4> if you can't query the queue status, you could end up with excessive buffering
[15:24:48 CEST] <nevcairiel> If you ignore the worker thread thing, you would just submit one packet and then call the nonblocking retrieve until it stops retunring things rinse and repeat
[15:25:08 CEST] <rcombs> wm4: maybe have a third parameter to _push and _pull
[15:25:16 CEST] <rcombs> for blocking or non-blocking
[15:25:34 CEST] <nevcairiel> If you add the worker thread, I would personally just block in submit as long as the thread is still busy
[15:25:50 CEST] <iive> the whole idea of separating these functions is to make them non-blocking.
[15:26:03 CEST] <iive> ok, half.
[15:26:20 CEST] <wm4> nevcairiel: then you need a way to asynchronously abort it or so... anyway, lots of details to decide
[15:26:38 CEST] <nevcairiel> Just skip the worker thread for now, its not needed
[15:27:40 CEST] <nevcairiel> And not sure abort is needed, just let it decode the current frame
[15:28:13 CEST] <wm4> what if getting the frame is blocking, or the input packet is not enough yet to produce a new frame
[15:28:30 CEST] <nevcairiel> That's why submit should block, not retrieve
[15:28:58 CEST] <wm4> then how do you know when there's a new frame?
[15:29:48 CEST] <nevcairiel> Once submit accepted a new frame, its either done with the previous one, or it needs more input
[15:30:19 CEST] <nevcairiel> I suppose you could add a blocking sync function if needed
[15:31:10 CEST] <iive> the current decode() could be implemented as ( if (av_decode_accept_data(avctx) ) av_decode_push(avctx,data);  if(av_decode_ready_data(avctx)) av_decode_pull(avctx,&data);} if the push/pull are blocking.
[15:31:52 CEST] <iive> hum.. 
[16:07:33 CEST] <rcombs> [matroska,webm @ 0x7ff2a3808000] Could not find codec parameters for stream 1 (Video: h264, none, 1280x720): unspecified pixel format <-- well that can't be good
[16:34:58 CEST] <rcombs> hmm, I'm hitting max_analyze_duration regardless of how high I set that value
[16:36:13 CEST] <rcombs> oh, actually, I can get it to work, and it just needs an absurdly high value for this file
[16:37:27 CEST] <rcombs> like, 1300000000
[16:40:35 CEST] <rcombs> &which seems like an overly large value for a 120-second file
[16:42:14 CEST] <rcombs> ...and the file plays fine in ffplay and mpv
[16:42:59 CEST] <wm4> so even if the warning happens, it plays fine?
[16:43:41 CEST] <rcombs> ffplay and mpv don't print the warning
[16:46:34 CEST] <rcombs> ffmpeg.c gives this: https://gist.github.com/78a69a90abe8c18818f0
[16:49:37 CEST] <rcombs> I have a local hack in configure_input_video_filter that passes AV_PIX_FMT_YUV420P to the scale filter if we get AV_PIX_FMT_NONE, which seems to fix this case (despite the actual stream being YUV420P10[LE])
[16:49:42 CEST] <wm4> seems like it relies on the AVStream codec context for this
[16:49:56 CEST] <wm4> (but I don't know the code)
[16:50:23 CEST] <wm4> mpv for example takes all pixel format information from frames returned by the decoder, and doesn't care whatever libavformat has found
[16:50:34 CEST] <wm4> +about
[16:51:09 CEST] <nevcairiel> i tend to blacklist streams with missing information, since they are often broken
[16:51:14 CEST] <nevcairiel> not sure i do it for pixfmt though
[16:52:03 CEST] <rcombs> mpv doesn't print the warning because it uses its internal matroska demuxer here, which doesn't call avformat_find_stream_info
[16:52:26 CEST] <rcombs> if I set `-demuxer lavf`, the warning is printed but everything proceeds normally
[16:54:00 CEST] <rcombs> in this case I actually need the pixel format, and the fact that it needs an analyzeduration higher than the actual file's duration seems like a bug
[16:54:16 CEST] <wm4> well this whole libavformat code is pretty hacky
[16:54:29 CEST] <wm4> and does a lot of scary things
[16:54:56 CEST] <wm4> should be all in utils.c
[17:10:55 CEST] <rcombs> ahhhhhh
[17:11:07 CEST] <rcombs> it's getting screwed up by a subtitle stream
[17:11:23 CEST] <rcombs> which has a few events that run practically forever
[17:14:54 CEST] <wm4> lol
[17:18:22 CEST] <rcombs> heh, and the code assumes that packets don't overlap
[17:18:26 CEST] <rcombs> within a single stream
[17:18:58 CEST] <rcombs> which is why I need a value significantly higher than the file duration (probably the total duration times the number of long-running events)
[17:21:40 CEST] <rcombs> well, easy enough to skip that duration handling on subtitle streams
[17:21:43 CEST] Action: rcombs `make fate`
[17:32:27 CEST] <rcombs> https://gist.github.com/9a149d36806a4c580acf well that can't be good
[17:33:48 CEST] <cone-698> ffmpeg 03James Almer 07master:4bb6cb4c7db4: x86/vp9mc: fix string concatenation of fullpel function names
[17:52:06 CEST] <RiCON> https://ffmpeg.org/general.html <- shouldn't Opus show as "E X" or doesn't the native decoder work?
[17:57:39 CEST] <durandal_1707> it was not updated
[18:36:58 CEST] <rcombs> https://gist.github.com/8d28f2e817d35cd05bb8 well that's odd
[18:39:11 CEST] <wm4> I have no idea what this is but yes it looks odd
[18:40:28 CEST] <rcombs> those are declared by LOCAL_ALIGNED_32(uint8_t, base0, [32 + 16 * 16 * 2]);
[18:40:48 CEST] <rcombs> which expands to& uint8_t __attribute__ ((aligned (32))) la_base0 [32 + 16 * 16 * 2] ; uint8_t (*base0) = la_base0;
[18:41:54 CEST] <wm4> does "p &la_base0[0]" give the same result?
[18:42:10 CEST] <durandal_1707> Unused function ff_avg_h264_qpel8or16..
[18:42:25 CEST] <wm4> durandal_1707: quick add an ifdef to silence the warning
[18:43:48 CEST] <rcombs> wm4: `p &la_base0[0]` gives the same result as `p &la_base0`
[18:44:01 CEST] <wm4> ok that's as it should be
[18:44:06 CEST] <rcombs> yup
[18:44:24 CEST] <rcombs> wonder if clang could actually be mis-compiling this
[18:44:54 CEST] <rcombs> seems like it's that or something's fucking up the stack, but I'd think that would generally be a bit less targeted
[18:45:02 CEST] <rcombs> (nothing else seems particularly out of the ordinary)
[19:03:10 CEST] <rcombs> ...ah
[19:03:24 CEST] <rcombs> I think something writes past the end of buf1
[19:03:33 CEST] <rcombs> or buf0
[19:06:21 CEST] <cone-698> ffmpeg 03Nicolas George 07master:807d4b635567: lavfi/buffersink: loop over ff_request_frame().
[19:06:22 CEST] <cone-698> ffmpeg 03Nicolas George 07master:7635242ae591: lavfi/vf_idet: remove the loop in request_frame().
[19:06:23 CEST] <cone-698> ffmpeg 03Nicolas George 07master:598f8a7afae6: lavfi/vf_idet: reindent after last commit.
[19:06:24 CEST] <cone-698> ffmpeg 03Nicolas George 07master:2a351f6c5521: lavfi: drop the requirement that request_frame returns a frame.
[19:06:25 CEST] <cone-698> ffmpeg 03Nicolas George 07master:44f660e7e75b: lavfi: remove FF_LINK_FLAG_REQUEST_LOOP.
[19:18:37 CEST] <jamrial> rcombs: valgrind seems to complain about it as well
[19:18:47 CEST] <jamrial> and so will gcc asan i bet
[19:18:47 CEST] <rcombs> yeah, I found the bug
[19:20:03 CEST] <rcombs> after `midoff_aligned = (dir ? 16 * 8 : 16) * SIZEOF_PIXEL;`, buf0 and buf1 aren't adjusted to reflect the new midoff values
[19:22:24 CEST] <rcombs> jamrial: while you're valgrinding, mind seeing if this patch makes it happy? https://gist.github.com/d5bfe7c8d7afcb7d3756
[19:22:40 CEST] <rcombs> (the earlier hunk is de-macro-izing that function for easier debugging)
[19:22:41 CEST] <jamrial> i'm not valgrinding, i saw it fail on fate :p
[19:22:48 CEST] <jamrial> but let me fire up a vm and i'll test it
[19:23:47 CEST] <jamrial> although looking again, it failed with a sigsegv, same as other fate clients
[19:27:22 CEST] <jamrial> rcombs: that fixed the failures for me on mingw at least
[19:27:49 CEST] <rcombs> same here, and it looks sane enough, so I'm sending
[19:30:17 CEST] <rcombs> sent
[19:30:46 CEST] <wm4> so, everyone must be on the way home from VDD now
[19:30:51 CEST] <wm4> did you guys reconcile yet?
[19:31:01 CEST] <wm4> were there any murders?
[19:59:04 CEST] <cone-698> ffmpeg 03Paul B Mahol 07master:2a0fc55995b7: avfilter: add rubberband wrapper
[20:21:47 CEST] <cone-698> ffmpeg 03Rodger Combs 07master:cf2719abeecb: lavf/matroska: ignore ChapCountry ID for now
[20:25:36 CEST] <Plorkyeran> no to both
[20:26:27 CEST] <wm4> surprise
[20:32:29 CEST] <Plorkyeran> obviously it's because you didn't come
[20:32:38 CEST] <Plorkyeran> if you were here everything would have gone perfectly
[20:44:06 CEST] <cone-698> ffmpeg 03Rodger Combs 07master:df2a2643fef4: tests/checkasm: fix stack smash in check_loopfilter
[21:34:27 CEST] <cone-698> ffmpeg 03Ganesh Ajjanagadde 07master:198110d702da: avcodec/hevc_mp4toannexb_bsf: silence -Wdiscarded-qualifiers
[21:52:51 CEST] <J_Darnley> Does one of the FFmpeg libraries have a function for checking that a string is valid UTF-8?
[21:56:56 CEST] <J_Darnley> Hmm... I could abuse av_utf8_decode in a loop.
[22:03:33 CEST] <wm4> I think there was, somewhere
[22:03:54 CEST] <wm4> after all libavcodec intentionally breaks reading of subtitles that are not utf-8
[22:04:58 CEST] <wm4> (which is 100% bullshit btw., especially considering ffmpeg tries so hard to read completely broken A/V streams, even if they're definitely invalid, and even if it rsisk handling valid streams correctly)
[22:06:11 CEST] <J_Darnley> Well... I am hoping to make flac muxing fail when the metadata has an invalid UTF-8 string.
[22:08:06 CEST] <wm4> such things should be fine when _writing_ files
[22:09:03 CEST] <J_Darnley> Not when when vorbis comments are UTF-8 and the metadata contains twice incorrectly converted japanese charachters
[22:31:29 CEST] <J_Darnley> Damn!  It doesn't fail.
[22:31:31 CEST] <J_Darnley> oh well
[22:34:01 CEST] <cone-698> ffmpeg 03Michael Niedermayer 07master:f67170e81b79: avdevice/libdc1394: add const to suppress "assignment discards const qualifier from pointer target type" warnings
[22:34:02 CEST] <wm4> if you mean misinterpeted gibberish that has been encoded to utf-8, of course not
[22:34:18 CEST] <wm4> I guess you could try to reverse it
[22:39:27 CEST] <J_Darnley> I certainly plan to.  I already know which code pages I need to go between.
[22:42:26 CEST] <J_Darnley> damn isp
[23:09:50 CEST] <cone-698> ffmpeg 03Pedro Arthur 07master:77367f61b38d: swscale: fix ticket 4850
[23:24:36 CEST] <Mavrik> Hmm, is there a reason libx264.c doesn't apply vbv parameters yet?
[23:24:45 CEST] <durandal_170> so what was on special meeting?
[23:40:52 CEST] <cone-698> ffmpeg 03Michael Niedermayer 07master:55b803e33ede: avcodec/snowenc: Remove unused new_picture field
[23:40:53 CEST] <cone-698> ffmpeg 03Michael Niedermayer 07master:01770bfda02a: avcodec/snowenc: Do not write into const AVFrame
[00:00:00 CEST] --- Mon Sep 21 2015