[Ffmpeg-devel-irc] ffmpeg-devel.log.20171223
burek
burek021 at gmail.com
Sun Dec 24 03:05:03 EET 2017
[00:00:03 CET] <iive> it's just pointers to blocks
[00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:28358e466d4f: avformat/http: return EINVAL from ff_http_do_new_request() if re-used with different hostname
[00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:9395e44b8d20: avformat/http: add "Opening" info logging to ff_http_do_new_request
[00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:b7d6c0cd48da: avformat/hls: add http_persistent option
[00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:03765aa6fa9c: avformat/hls: allow open_input to be re-used
[00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:1f0eaa02aa71: avformat/hls: add http_multiple option
[00:03:59 CET] <wm4> tmm1: so is this still not enabled by default, or how is it used?
[00:04:58 CET] <tmm1> its enabled by default now
[00:05:23 CET] <tmm1> i just sent some more benchmarks to the list
[00:05:29 CET] <tmm1> 3x throughput improvement on a random internet stream i just tried
[00:11:40 CET] <wm4> nice
[00:13:04 CET] <StevenLi_> Great :)
[00:14:06 CET] <wm4> does DASH benefit from this too?
[00:14:24 CET] <kierank> iive: and in mpv_reconstruct_mb_internal how do know how to write coefficients to dest_y, cr, cb?
[00:14:27 CET] <tmm1> only if the hls.c changes are copied over
[00:16:15 CET] <iive> kierank: in i420 you have 6 blocks, 4 y, 1 cr and 1cb. you just point them to the correct possitions, then point to the ctx->blocks[][] .
[00:16:25 CET] <kierank> it's 10-bit 444
[00:16:40 CET] <kierank> but then the dct does stuff and puts them in dest_y, cr, cb
[00:16:43 CET] <StevenLi_> tmm1: can you merge it into dashdec by the way? :D
[00:16:44 CET] <iive> the contex even have the pointers pre-calculated in the ctx
[00:17:05 CET] <iive> you'd just have to tweak the formula or abstract the function to update it.
[00:17:32 CET] <kierank> but when I decode the dpcm data it's before I know where to put it
[00:17:43 CET] <iive> how so?
[00:17:48 CET] <StevenLi_> by the way my means "if you convenient" :D
[00:17:55 CET] <iive> you don't decode the image MB by MB ?
[00:19:29 CET] <kierank> when I rebase I'll show you
[00:23:27 CET] <kierank> iive: https://github.com/kierank/ffmpeg-sstp/blob/master/libavcodec/mpeg4videodec.c#L1990
[00:23:35 CET] <kierank> well i have to know where to decode the dpcm data
[00:23:40 CET] <kierank> I can't just use s->block
[00:23:46 CET] <kierank> or block2 in my case
[00:31:46 CET] <iive> the code has exit(0) there. Don't you have it implemented with a memcpy?
[00:32:00 CET] <kierank> not yet
[00:32:07 CET] <kierank> because i don't know where to put the coefficients
[00:34:55 CET] <wm4> what does PCM mean in context of video?
[00:35:54 CET] <kierank> wm4: the block data is coded directly in the bitstream (no transform, quantisation etc)
[00:36:10 CET] <iive> a raw bitmap
[00:36:50 CET] <kierank> so where do I put the data
[00:45:59 CET] <iive> why you cannot put it in block2 ?
[00:47:23 CET] <iive> you can put some special mb mode, e.g. mb_intra=2 and do memcpy instead of dct later.
[00:47:31 CET] <kierank> so there's no way of doing it without memcpy
[00:47:39 CET] <kierank> because of mpegvideo.c being terrible
[00:47:40 CET] <kierank> great
[00:47:48 CET] <iive> i didn't said that
[00:48:10 CET] <iive> imho, ctx->dest[] should already be set before starting decoing
[00:48:19 CET] <iive> decoding
[00:49:03 CET] <iive> decoding of the MB
[00:51:17 CET] <iive> ff_init_block_index()
[00:51:43 CET] <kierank> yes but what about
[00:51:43 CET] <kierank> dest_y
[00:51:46 CET] <kierank> if(readable){
[00:51:46 CET] <kierank> dest_y= s->dest[0];
[00:51:46 CET] <kierank> dest_cb= s->dest[1];
[00:51:46 CET] <kierank> dest_cr= s->dest[2];
[00:51:46 CET] <kierank> }else{
[00:51:46 CET] <kierank> dest_y = s->sc.b_scratchpad;
[00:51:47 CET] <kierank> dest_cb= s->sc.b_scratchpad+16*linesize;
[00:51:47 CET] <kierank> dest_cr= s->sc.b_scratchpad+32*linesize;
[00:51:48 CET] <kierank> }
[00:52:02 CET] <kierank> and also lowres of course
[00:54:19 CET] <iive> I think a little bellow there is a code that copies the scratchpad to the dest[] possition.
[00:55:29 CET] <kierank> but that happens after the coeffs are done
[01:03:27 CET] <iive> you can just add another condition to set readable, that is special case for you and not bother with scratchpad
[01:05:30 CET] <iive> actually if you use dest[] in the coefficients code, you can literally skip the most of the function.
[01:09:35 CET] <kierank> yes, the point is that if s->dest is valid
[01:17:15 CET] <iive> it should be valid at all time, it should be set at slice start and updated after every mb decoded.
[01:18:52 CET] <kierank> and how do I make s->block int32-t without it breaking everything
[01:18:56 CET] <kierank> and causing speed issues
[01:30:12 CET] <iive> i'll leave that for another day.
[01:30:26 CET] <wm4> jkqxz: looking at this cabac x264 bug - is there a magic bsf command line that adds SEI + user data to every packet?
[01:30:47 CET] <kierank> iive: :(
[01:31:40 CET] <kierank> michaelni: are the ffmpeg golomb codes the 00001 variant or the 11110 variant?
[01:33:27 CET] <kierank> actually it's not a golomb i'm reading
[01:33:38 CET] <atomnuker> pretty sure they're all the 00001 variant
[01:33:52 CET] <kierank> atomnuker: do you know what the helper function is for these kind of VLCs?
[01:33:56 CET] <kierank> https://usercontent.irccloud-cdn.com/file/JhAKV5Gn/image.png
[01:34:46 CET] <kierank> i think the native type actually
[01:43:04 CET] <cone-218> ffmpeg 03Aman Gupta 07master:54d0ef1738ff: avformat/http: return EOF from ff_http_do_new_request if previous response said Connection:close
[01:43:05 CET] <cone-218> ffmpeg 03Aman Gupta 07master:5f4a32a6e343: avformat/hls: hide misleading warning when http reconnect is required
[01:51:13 CET] <kierank> atomnuker: how much do you know about rice codes
[01:53:12 CET] <atomnuker> only that they're a superset of golomb codes (or was it the opposite)
[01:53:22 CET] <atomnuker> jdarnley ought to know more, flac uses them
[01:53:50 CET] <nevcairiel> rice is a special golomb
[01:54:06 CET] <jdarnley> Sorry I think I only know reverse-golomb from Dirac.
[01:55:21 CET] <kierank> https://usercontent.irccloud-cdn.com/file/qsPyxIbG/image.png
[01:55:30 CET] <kierank> atomnuker: any idea how to calculate the length of dpcm_residual
[01:57:19 CET] <kierank> it just says "dpcm_residual: This is an unsigned integer that indicates the value of a DPCM residual"
[01:58:08 CET] <nevcairiel> shouldnt the definiton of "uimsbf" tell you how to parse those values
[01:58:25 CET] <kierank> sure, but doesn't explain the 4-12
[01:58:44 CET] <nevcairiel> how did you figure out the length of say block_mean. its 8-12 uimsbf
[01:59:10 CET] <kierank> block mean is the average of the block and the supported bitdepths are 8-12
[02:01:31 CET] <nevcairiel> so basically the format syntax is just bonkers
[02:10:12 CET] <kierank> there must be something I'm missing
[02:11:13 CET] <jkqxz> wm4: The h264_metadata sei_user_data option adds it to the first packet and then every packet containing an SPS.
[02:11:23 CET] <wm4> yeah you wrote that
[02:11:35 CET] <jkqxz> It kindof wants to go in the extradata, but that doesn't work for H.264.
[02:12:06 CET] <nevcairiel> yeah they changed their minds with hevc and have a slot for sei in extradata
[02:12:12 CET] <Chloe> https://0x0.st/s8cg.err could this be caused by parsers not being loaded correctly?
[02:12:16 CET] <jkqxz> (Because AVCC is too restrictive.)
[02:12:22 CET] <wm4> anyway, I'm trying to fix it for playback use, fixing it with a bsf is just a curiosity
[02:12:43 CET] <nevcairiel> detecting it would be nice, but not sure its in any way easy
[02:12:49 CET] <wm4> especially the fact that it doesn't works with initial seeks sucks
[02:12:54 CET] <wm4> -s
[02:12:56 CET] <Chloe> seems to fail decoding the code block due to an overread/underread(?)
[02:13:19 CET] <Chloe> i dont really know how jpeg2000 works
[02:14:30 CET] <jkqxz> Detecting it is not fun. You're pretty much stuck with "if the whole frame fails to decode, try again in the other mode".
[02:14:48 CET] <wm4> my current sucky idea is adding a h264 avoption to set the x264 build (if unset), and prefetching the first video packet in the demuxer to parse the x264 version
[02:15:15 CET] <wm4> jkqxz: shouldn't decoding be mostly stateless, other than for frame management?
[02:15:21 CET] <nevcairiel> that fixes the seek issue, but not the broken files
[02:15:27 CET] <wm4> nevcairiel: yes
[02:15:37 CET] <wm4> but better than nothing
[02:16:16 CET] <wm4> I'd go as far as saying the h264 decoder should actually assume a buggy x264 if the version is unset and std compliance is not set to strict, but I'm sure that'd make everyone hate me
[02:16:40 CET] <Chloe> how would I begin to debug this?
[02:16:54 CET] <wm4> Chloe: is it a regression?
[02:17:20 CET] <Chloe> I assume git master passes all fate, so probably
[02:17:37 CET] <wm4> then bisect
[02:17:43 CET] <jkqxz> Yes. It is certainly possible. It's just not directly detectable because the arithmetic coding is carefully designed not to be redundant, so all you can see is some unclear error sometime after the failure point.
[02:18:37 CET] <wm4> jkqxz: my thought for this was unset x264_build + using 4:4:4 + decoding fails "somehow" -> enablw workaround
[02:18:39 CET] <wm4> *enable
[02:18:45 CET] <wm4> but that is icky too
[02:19:24 CET] <Chloe> wm4: I mean it'd only be one commit which breaks it, so not sure how bisect would help (I'm checking git master now)
[02:20:24 CET] <wm4> oh
[02:24:52 CET] <kierank> durandal_1707: ping
[02:25:48 CET] <Chloe> wm4: yep, my patch definitely breaks it, somehow.
[02:27:57 CET] <wm4> Chloe: maybe a parser gets not found (or the wrong one or something like this)
[02:30:12 CET] <wm4> why do we have stuff like ff_mutex_init?
[02:30:19 CET] <wm4> instead of defining pthread stubs
[02:33:23 CET] <Chloe> oh. so this test encodes in mjpeg first then decodes--probably choosing the wrong parser or just not choosing it at all
[02:33:57 CET] <jamrial> wm4: there's a hardened version when using pthreads, and it works with no threading at all
[02:35:35 CET] <jamrial> if you use pthreads directly (native or w32/os2 emulation) you'd have to wrap everything under HAVE_THREADS checks
[02:36:25 CET] <wm4> not sure what you mean, but this means I'll have to use AVMutex etc. in my patches (I don't want an ifdef soup)
[02:37:39 CET] <jamrial> that's what i mean. you just do ff_mutex_lock() instead of #if HAVE_THREADS pthreads_mutext_lock() #endif
[02:39:20 CET] <Chloe> could just define pthreads_mutext_lock() as a noop macro if !HAVE_THREADS too
[02:39:34 CET] <wm4> seems like we posted about this at pretty much the same time
[02:39:55 CET] <wm4> Chloe: yeah, but for some reason it was explicitly not done - who knows why
[02:40:17 CET] <Chloe> jamrial: why not use a noop macro?
[02:40:18 CET] <wm4> because at ASSERT_LEVEL>1 we do: #define pthread_mutex_init strict_pthread_mutex_init
[02:41:13 CET] <jamrial> that's for native pthreads only, though
[02:41:55 CET] <jamrial> w32threads.h could define a bunch of noop macros, but i think it would be best if we instead just use AVMutex everywhere
[02:42:22 CET] <wm4> what I mean is, we override the pthread standard names with our own stuff anyway at high assert levels
[02:42:43 CET] <Chloe> why AVMutex over using/emulating/noop-ing pthreads everywhere?
[02:44:27 CET] <wm4> that's the question
[02:44:42 CET] <wm4> I think the argument was something about not conflicting with standard names?
[02:44:52 CET] <Chloe> in atomics (once I've removed the avpriv stuff), we use normal atomics everywhere and define normal atomics for win32 which doesnt support stdatomic
[02:44:59 CET] <wm4> thus why I mentioned this ASSERT_LEVEL stuff
[02:45:06 CET] <Chloe> wm4: but we do this with stdatomic
[02:45:09 CET] <wm4> yeah
[02:45:17 CET] <Chloe> there shouldnt be any reason not to do it with pthread
[02:45:27 CET] <wm4> maybe I'll send a patch later to get rid of that
[02:45:33 CET] <wm4> for now I'll use AVMutex
[02:46:08 CET] <wm4> michaelni: any other comments on that patch set before I update/rebase/resend them?
[02:47:28 CET] <jamrial> wm4: for that matter, don't remove the InitializeCriticalSection and WaitForSingleObject redefinitions in w32threads.h
[02:47:36 CET] <jamrial> even if they are unused inside that header after your patch, they are used elsewhere
[02:48:02 CET] <jamrial> dxva2.c, dshow.c, vfwcap.c, hwcontext_d3d11va.c
[02:48:39 CET] <jamrial> WaitForSingleObject is, at least
[02:49:09 CET] <wm4> is that for winrt or something?
[02:49:40 CET] <jamrial> no, for _WIN32_WINNT >= 0x0600, which will be the default now
[02:50:12 CET] <wm4> I don't get it, what is that for?
[02:50:53 CET] <wm4> these are normal win32 API available everywhere
[02:51:42 CET] <jamrial> yes, the define is to force the usage of WaitForSingleObjectEx instead of WaitForSingleObject on Vista or newer
[02:53:02 CET] <jamrial> why is it needed? i don't know, but lets not remove it unless there's a reason to
[02:53:16 CET] <wm4> nevcairiel: any clue?
[02:54:11 CET] <wm4> ah 428b0578c64241fc677fed7083cc8fe65e10f32e
[02:54:54 CET] <wm4> claims winrt doesn't have them (unlike MSDN)
[02:55:02 CET] <jamrial> so yeah, winrt related after all
[02:55:23 CET] <jamrial> well, we don't have winrt fate clients to check if that's still true
[02:56:27 CET] <jamrial> and again, unrelated to your patch in any case
[02:56:35 CET] <wm4> yeah
[02:57:59 CET] <wm4> I might be stupid, but how do you get the original avctx/context in AVCodec.init_thread_copy?
[02:58:01 CET] <michaelni> wm4, i didnt had the time to look at the set, just looked briefly at one patch, so no other comments from me on the set. ill look tomorrow if i have time and if its not applied yet
[02:58:29 CET] <wm4> michaelni: ok, then I'll wait
[03:01:40 CET] <cone-218> ffmpeg 03Aman Gupta 07master:4c78bbd3136a: avformat/internal: log underlying error with ff_rename failure
[03:06:19 CET] <mistym> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222811.html Anyone have a suggestion on a good way to handle this? http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222811.html
[03:17:50 CET] <jamrial> mistym: just put them directly in a header
[03:18:29 CET] <jamrial> we have big tables in headers, these 5 element arrays are no issue
[03:19:06 CET] <mistym> Oh okay, sounds easy enough. Should they be renamed when I do that?
[03:19:10 CET] <jamrial> no, you can keep the ff_ suffix that way, as well
[03:19:20 CET] <mistym> Oh great, thanks!
[03:37:13 CET] <mistym> jamrial: Is there a good place to look at an example of something that's done this? I'm not sure how to avoid duplicate symbols when linking
[03:38:36 CET] <Chloe> wouldnt declaring them as static work
[03:38:49 CET] <jamrial> mistym: mpeg4data.h
[03:39:04 CET] <jamrial> and yes, what Chloe said, declare them as static const
[03:39:10 CET] <mistym> Thanks!
[03:40:57 CET] <wm4> jamrial, Chloe: well that would duplicate them in both binaries, but good enough
[03:41:47 CET] <jamrial> they are five elements each. better this than having them as avpriv_
[03:47:42 CET] <mistym> Yeah, that did it, and `make fate` passes; thanks!
[05:31:17 CET] <Chloe> atomnuker: you said you had some sed for the filter insanity
[05:31:18 CET] <Chloe> ?
[06:43:52 CET] <cone-498> ffmpeg 03Vishwanath Dixit 07master:d02289c386ec: avformat/hlsenc:addition of #EXT-X-MEDIA tag and AUDIO attribute
[09:11:16 CET] <atomnuker> Chloe: mod the filter file to remove all #includes
[09:11:18 CET] <atomnuker> then just
[09:11:21 CET] <atomnuker> gcc -E libavcodec/allcodecs.c | cut -c 7- | cut -d ";" -f 1 | perl -i -pe 's/$/;/' | sed -r '/^.{,3}$/d'
[09:11:26 CET] <atomnuker> except with the filter file
[09:13:32 CET] <durandal_1707> kierank: pong
[11:42:35 CET] <cone-897> ffmpeg 03Paul B Mahol 07master:4754d70a2325: avfilter/video: pick sar from link
[11:42:35 CET] <cone-897> ffmpeg 03Paul B Mahol 07master:f6608f472553: avfilter/vf_aspect: change outlink sample aspect ratio instead of inlink
[11:42:35 CET] <cone-897> ffmpeg 03Paul B Mahol 07master:b943bc343de0: avfilter/vf_fftfilt: support >8 bit depth formats
[14:18:27 CET] <durandal_1707> found bug in convolve filter, nobody understands this shit
[14:31:10 CET] <Chloe> atomnuker: put lavc list patch on before i start working on the other libs, don't want to start them unless lavc one looks alright
[14:35:19 CET] <RiCON> tmm1: 4c78bbd3136 broke compilation with --enable-decklink https://i.fsbn.eu/KGUy.txt
[15:38:32 CET] <thardin> what's the libav* way of counting the number of elements in an array?
[15:38:35 CET] <thardin> I recall there being a macro
[15:46:10 CET] <thardin> FF_ARRAY_ELEMS
[15:47:21 CET] <atomnuker> yes
[16:05:05 CET] <thardin> it's a bit meh that --enable-ffplay silently fails if libsdl2 isn't installed
[16:27:09 CET] <jdarnley> Lots of the enable options silently fail if some lib is not installed. Quite annoying sometimes.
[16:28:03 CET] <jdarnley> I remember the time when I didn't have zlib installed and nothing would actually make configure fail.
[16:29:07 CET] <wm4> should have brhaved more like autoconf
[16:29:13 CET] <wm4> behaved
[16:29:55 CET] <jdarnley> What? Continue as normal then at the end print a message "I don't know what --enable-whatever means"?
[16:30:05 CET] <jamrial> i think it's easy to fix. ubitux wrote this request() feature for autodetected libs that are explicitly requested in the command line
[16:30:09 CET] <thardin> jdarnley: it catches that
[16:30:22 CET] <jamrial> should be a matter of adding ffplay to it
[16:30:45 CET] <jdarnley> sure, it might catch zlib *now*
[16:33:10 CET] <jamrial> thardin: try https://pastebin.com/kUr1WinN
[16:37:51 CET] <thardin> giving it a go
[16:38:48 CET] <wm4> jdarnley: I thought it'd fail
[16:40:28 CET] <thardin> jamrial: purged libsdl2-dev, did ./configure --enable-ffplay
[16:40:37 CET] <thardin> configure succeeded, no ffplay among programs
[16:40:53 CET] <jamrial> mmh
[16:42:13 CET] <jamrial> what did you mean with "silently fails" for that matter?
[16:43:47 CET] <thardin> jamrial: silently accepts is perhaps more apt
[16:43:54 CET] <thardin> like I request ffplay but don't ge tit
[16:44:52 CET] <jamrial> what should happen is that configure should fail and emit an error, much like when you do --enable-libwhatever and said library is not available
[16:45:48 CET] <thardin> yeah that doesn't happen
[16:47:15 CET] <jamrial> not even with the above patch?
[16:48:21 CET] <thardin> unless I did something wrong in applying it. git diff seems as expected
[16:55:44 CET] <RiCON> tmm1: found this thread discussing it back in 2013 https://ffmpeg.org/pipermail/libav-user/2013-January/003440.html
[16:57:31 CET] <wm4> is there a problem with av_err2str somewhere?
[16:58:18 CET] <wm4> oh damn
[16:58:38 CET] <RiCON> yeah, it doesn't work in c++
[16:58:39 CET] <wm4> I guess some C++ files might include that file (maybe the decklink wrapper)
[16:58:49 CET] <RiCON> it includes avformat/internal.h
[16:58:53 CET] <wm4> and the macro requires C99
[16:59:18 CET] <wm4> it'll have to call av_strerror directly then
[16:59:27 CET] <wm4> which is slightly less convenient, but no deal breaker I guess
[17:00:07 CET] <wm4> (also I'd like to object that fact how horribly all this stuff is hacked into header files, probably to allow sharing between the sub-libs)
[17:00:15 CET] <wm4> (can we kill the sub-libs separation yet)
[17:15:27 CET] <rcombs> wm4: it's possible to work around in C++ using a static inline function and a struct containing the array
[17:24:25 CET] <wm4> rcombs: how?
[17:24:47 CET] <wm4> something like fn().field ?
[17:24:57 CET] <rcombs> yeah
[17:25:12 CET] <wm4> could work I guess
[17:25:14 CET] <rcombs> actually you could probably do it with just a struct containing the array and a macro
[17:25:29 CET] <rcombs> the only thing about it that doesn't work in C++ is the inline array declaration
[17:54:12 CET] <cone-890> ffmpeg 03Paul B Mahol 07master:b5958ff82eed: avfilter/vf_convolve: unbreak non-power of 2 width&height filtering
[18:55:20 CET] <tmm1> ugh
[19:06:58 CET] <wm4> tmm1: sorry, heh
[19:11:15 CET] <kierank> so I have mpeg4 pixel formats that aren't in ff_h263_hwaccel_pixfmt_list_420
[19:11:17 CET] <kierank> what do I do?
[19:11:20 CET] <kierank> add them?
[19:11:28 CET] <kierank> in fact they aren't even 420
[19:12:22 CET] <wm4> I think those are for hwaccels only, and no hwaccel won't support 444, so don't add them?
[19:13:12 CET] <kierank> but it's needed in the pix_fmts struct
[19:13:20 CET] <wm4> (I think it's all about whether get_format will include hwaccel formats if the decoder pixfmt is in that list)
[19:14:03 CET] <wm4> .pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
[19:14:04 CET] <wm4> oh.
[19:14:36 CET] <wm4> you can probably take inspiration from the h264 code (which needs to support both hwaccels and non-hw decodable formats)
[19:14:47 CET] <wm4> of course it's a mess
[19:15:21 CET] <durandal_1707> thats for encoding only i think
[19:15:39 CET] <kierank> I can't actually get my decoder to work without putting the desired pixel format at the top of that list
[19:15:41 CET] <wm4> no this is on ff_mpeg4_decoder
[19:15:49 CET] <kierank> i get complaints about reconfiguring the pipeline pixel format
[19:16:38 CET] <durandal_1707> huh, cant it be got in init?
[19:17:37 CET] <wm4> kierank: ff_get_format should be called with only 1 sw pixfmt
[19:17:51 CET] <wm4> so you need to switch between different lists, basically
[19:18:19 CET] <wm4> libavcodec itself will always select the first sw pixfmt for normal decoding, I think
[19:18:26 CET] <kierank> "[mpeg4 @ 0x27ccda0] format change not supported"
[19:19:04 CET] <kierank> somewhere there is a big yuv420p assumption
[19:19:37 CET] <durandal_1707> where you set pixel format?
[19:21:01 CET] <kierank> https://github.com/kierank/ffmpeg-sstp/blob/master/libavcodec/mpeg4videodec.c#L3075
[19:21:06 CET] Action: kierank bbl
[19:32:02 CET] <durandal_1707> look where is yuv420p set
[19:52:21 CET] <durandal_170> michaelni: https://nvd.nist.gov/vuln/detail/CVE-2017-17555
[20:11:28 CET] <tmm1> RiCON: does this work https://paste.ubuntu.com/26240610/
[21:18:00 CET] <RiCON> tmm1: yes, that worked
[21:32:52 CET] <tmm1> RiCON: great will commit
[21:33:14 CET] <RiCON> don't forget to mention ticket #6926
[21:33:29 CET] <tmm1> im afk for a bit, so if you want to commit go ahead
[21:33:40 CET] <RiCON> i don't have push access
[21:38:04 CET] <cone-744> ffmpeg 03Aman Gupta 07master:9e5e3236f4f2: avformat/internal: fix compile error with some versions of g++
[21:43:08 CET] <michaelni> durandal_170, ive seen this before, its a bug in aubio, it sets up the resampler for stereo and sends mono data, which crashes because mono doesnt have a 2nd channel, its also there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884232
[21:44:25 CET] <durandal_170> i got immpresion that swr doesnt check pointers?
[22:59:19 CET] <thardin> sending in an updated codec2 patchset soon
[23:17:28 CET] <thardin> there we go
[00:00:00 CET] --- Sun Dec 24 2017
More information about the Ffmpeg-devel-irc
mailing list