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

[burek]

[00:00:09 CET] <durandal_1707> kierank: what next you gonna fuzz?
[00:00:18 CET] <kierank> fuzzing vp9 currently
[00:01:05 CET] <durandal_1707> mjpeg?
[00:02:56 CET] <kierank> dunno, if you've done ffv1 then I won't
[00:13:19 CET] <wm4> why not fuzz libavformat
[00:13:59 CET] <durandal_1707> I Donne 1 cycle of version 3
[00:35:01 CET] <kierank> wm4: because I don't use libavformat
[00:35:28 CET] <wm4> aren't you lucky
[01:23:00 CET] <kierank> durandal_1707: cool
[01:44:10 CET] <cone-942> ffmpeg 03Michael Niedermayer 07master:5745cf799a43: avcodec/ffv1dec: Check for 0 quant tables
[01:44:11 CET] <cone-942> ffmpeg 03Michael Niedermayer 07master:c665532820d9: avcodec/ffv1dec: Free tables on init failure
[01:44:12 CET] <cone-942> ffmpeg 03Michael Niedermayer 07master:a8b254e436dc: avcodec/ffv1dec: Print an error if the quant table count is invalid
[06:45:44 CET] <canaar> There's this snippet in ffserver.c : https://paste.hamaralinux.org/?e717ecf091d6dfe6#/j0EV6iL4fW10tjfdX7O+oZnLmg+rOW+4zf3TJEvkqY= 
[06:46:15 CET] <canaar> Why does it return 0 if there is a failure?. At many places it returns -1, whenever there's an error
[07:04:08 CET] <Compn> can
[07:04:09 CET] <Compn> doh
[07:14:51 CET] <reynaldo> canaar: I have stumbled at that one before but Im honestly not sure
[07:15:08 CET] <reynaldo> with 0 it will end up closing the connection iirc
[07:15:28 CET] <reynaldo> ad that codepath, it returning 0 that is should alctually not being hit
[07:15:32 CET] <reynaldo> but thats from memory
[07:15:38 CET] <reynaldo> will take another look tomorrow
[10:34:32 CET] <JamJams> Is there any good examples of using yadif in a filtergraph? I already have decoding and encoding down. I just need to add a filtergraph, something I've never attempted before.
[10:35:17 CET] <JamJams> https://www.ffmpeg.org/doxygen/0.9/filtering_8c-source.html < Is that still a good place to start?
[10:36:12 CET] <durandal_1707> ffmpeg and ffplay have code too
[10:37:43 CET] <JamJams> I don't really want to go digging around in that monster lol
[10:41:23 CET] <wm4> libavfilter is relatively easy to use, but requires quite a lot of weird boilerplate to setup
[10:41:45 CET] <wm4> ah there are actually filtering examples
[10:42:48 CET] <JamJams> I'm well versed in libavcodec but oddly enough I've never had to touch the filters... Yet...
[10:43:53 CET] <JamJams> https://trac.ffmpeg.org/attachment/ticket/25/yadif-libavfilter.c
[10:44:23 CET] <JamJams> That one looks ok, I was more worried they would be really dated and have bad practises
[10:45:05 CET] <BtbN> That nvenc/cuda patch...
[10:45:44 CET] <wm4> JamJams: the doxygen thing you linked is even older
[10:46:28 CET] <JamJams> Yeah the grayscale stuff put me off using that
[10:46:29 CET] <wm4> try this https://www.ffmpeg.org/doxygen/2.8/filtering_video_8c-example.html
[10:46:46 CET] <wm4> that doesn't matter
[10:47:50 CET] <JamJams> It was more how in the filtergraph code it was changing the pix format and stuff to allow for a grayscale output
[10:48:12 CET] <JamJams> I just want to deinterlace the input frames and have it spit out the raw yuv.
[10:48:44 CET] <JamJams> That's a nice example wow, that's pretty easy
[10:49:38 CET] <JamJams> I thought you'd have to avfilter_get_by_name("...") for each filter you wanted to use. But you can just pass it args and it does it all for you :/
[10:49:58 CET] <wm4> that's the filter graph parser (it's optional, you can do it either way)
[10:51:39 CET] <JamJams> Wouldn't it be better to do it the other way? Less overhead, then again I guess after it's initialised it probably wont impact performance any. 
[11:47:40 CET] <ubitux> wtf is this nvenc_ptx.c
[11:47:49 CET] <ubitux> Generated by NVIDIA NVVM Compiler omg
[11:54:18 CET] <wm4> yeah, I don't know wtf is going on in that patch
[11:59:50 CET] <rcombs> https://gist.github.com/bcc1b73070a4597eedcd uhhhhhhhhh
[12:00:44 CET] <ubitux> rcombs: clip_[u]intp2 funcs on arm can't take !constant
[12:00:54 CET] <ubitux> (i kinda dislikes this btw)
[12:01:08 CET] <ubitux> we need a fallback for the non constant
[12:01:49 CET] <rcombs> it's a constant arg, but the compiler doesn't inline it because I'm building with --disable-optimizations
[12:02:07 CET] <flux> :-)
[12:02:35 CET] <ubitux> rcombs: can you use av_builtin_constant_p() to fallback on a safer version?
[12:03:48 CET] <rcombs> lemme see
[12:04:10 CET] <wm4> I like how it says "probably"
[12:04:22 CET] <rcombs> ~gcc~
[12:04:53 CET] <flux> I wonder, does it do that warn every time? if it depends on optimizations to make it work? sorry, I don't know how to read those constraints :)
[12:05:48 CET] <rcombs> ubitux: safer version being av_clip_uintp2_c?
[12:06:01 CET] <ubitux> yeah i guess
[12:13:00 CET] <rcombs> ubitux: yeah, that works
[12:13:32 CET] <rcombs> https://gist.github.com/e5c55681a10f59ec192f duplicated implementation since it would produce circular header dependencies otherwise
[12:13:56 CET] <rcombs> you could probably do better if you wanted but ~lazy~
[12:15:28 CET] <rcombs> same thing in av_clip_intp2_arm
[12:18:21 CET] <durandal_1707> stupid microoptimizations
[12:19:15 CET] <wm4> the mfx vpp patch was terrible too
[12:20:31 CET] <ubitux> rcombs: why not #define av_clip_uintp2_arm(a, p) av_builtin_constant_p(p) ? av_clip_uintp2_arm_constant(a, p) : av_clip_uintp2_c(a, p)
[12:20:33 CET] <ubitux> ?
[12:20:57 CET] <rcombs> ubitux: because p _is_ constant
[12:21:08 CET] <rcombs> ubitux: the function just isn't getting inlined
[12:21:17 CET] <rcombs> so in the caller it's constant and in the callee it's not
[12:21:19 CET] <ubitux> ah mmh ok right
[12:21:48 CET] <rcombs> and afaik you can't declare an `unsigned` to __asm__ into in a macro
[12:22:10 CET] <rcombs> well, you can, but you can't also make the macro evaluate to that variable's value
[12:53:55 CET] <JamJams> When I attempt to create a buffersrc with avfilter_graph_create_filter I get error code -12 :/ I copied directly from the example, not sure why it would happen.
[12:58:05 CET] <JamJams> Doh, never mind I forgot to avfilter_register_all, that being said I'm still crashing. But that's solved :)
[13:03:07 CET] <michaelni> ubitux, interrested in a gifdec pull request:?https://github.com/FFmpeg/FFmpeg/pull/159
[13:12:50 CET] <wm4> wow, 2 guys who simply ignored the warning message
[13:13:08 CET] <JamJams> If you load the decimate filter with avfilter_graph_parse_ptr it results in avfilter_graph_config throwing error -22
[13:13:12 CET] <wm4> actually 6
[13:13:13 CET] <wm4> jesus
[13:13:14 CET] <JamJams> Is there something I'm missing here
[13:14:28 CET] <wm4> JamJams: any log messages? anyway, this should go on #ffmpeg
[13:15:45 CET] <JamJams> Nothing that I can see, ahh probably yes
[13:16:22 CET] <JamJams> This seems like a bug that may need to be patched though, so it's sorta relevant here
[13:17:36 CET] <wm4> works for me in ffmpeg and mpv
[13:25:59 CET] <JamJams> It's not working with this example though, which is odd.
[13:32:53 CET] <JamJams> The only core diff between the example an mpv is the linking of the "format" filter. Perhaps the example needs to be updated to include that. Although I still need to see if that fixes the issue.
[13:36:28 CET] <durandal_1707> wmapro compression is comparable to aac
[14:21:00 CET] Action: Daemon404 pokes peloverde re: demuxed vids
[14:41:48 CET] <wm4> JamJams: well what _is_ your error? it sounded like there are in fact log messages
[14:43:42 CET] <JamJams> There is no log messages from libavcodec, it simply fails on avfilter_graph_config and I wrote a statement to throw the return code which is -22. It only happens if decimate is in the filtergraph.
[14:46:56 CET] <JamJams> Calling avfilter_get_by_name("decimate") I can see that the filter is registered. So that's not the issue.
[14:50:45 CET] <wm4> I know that for me decimate fails by default if the framerate is not set
[14:56:57 CET] <ubitux> michaelni: i never worked on the decoder
[14:57:03 CET] <ubitux> (or not much)
[15:01:58 CET] <JamJams> wm4 thanks for that, the example doesn't set the timebase correctly. And even when hard-coded it fails but adding fps= to the front of the filtergraph bla bla fixes it right up
[15:02:29 CET] <wm4> well then you ignored the log messages
[15:03:55 CET] <JamJams> I wasn't getting any that's the thing
[15:07:18 CET] <wm4> that's strange then
[15:07:36 CET] <JamJams> Quite :/
[15:19:37 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:a813cdda487e: avcodec/truemotion1: Initialize mb_change_byte only when needed
[15:19:38 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:93f30f825c08: avcodec/hevc_ps: Check chroma_format_idc
[15:47:24 CET] <Gramner> wow, let's encrypt has the most obnoxious certificate signing procedure I've ever seen. what's up with having to install custom software on the server machine (with a bunch of prereqs as well) and run various scripts and stuff instead of a just a simple web interface or whatever. also as an added "feature" the certs are only valid for 90 days instead of a year which is standard
[15:50:26 CET] <thardin> because you can script things
[15:50:52 CET] <kierank> hmmm the j00ru guy has come back
[15:51:00 CET] <thardin> shell >> lolweb
[15:51:52 CET] <durandal_1707> kierank: you are late, it was yesterday or even before
[15:52:11 CET] <kierank> 20 hours ago
[15:54:24 CET] <kierank> vp9 fuzzing very slow
[15:54:35 CET] <Gramner> thardin: scripting stuff is really not worth it when renewing a cert manually once a year takes about a minute.
[15:54:56 CET] <Gramner> if you have hundreds of servers, sure
[15:56:16 CET] <durandal_1707> kierank: you use vp9?
[15:56:29 CET] <kierank> no not really but I fuzzed all the codecs I use
[16:00:38 CET] <Gramner> the letsencry software is also as bloated as most windows printer drivers. it downloaded 50MB of various random stuff and then failed with a vague error message
[16:01:43 CET] <thardin> the 90 day thing is probably temporary. either way you could set up cron to do it for you
[16:02:48 CET] <thardin> the local crypto nerds I know have been successfully using letsencrypt for a while
[16:03:48 CET] <flux> gramner, I wouldn't assume the 'final' certs are going to be 90 days as well, given it's now in "limited beta"
[16:04:27 CET] <Gramner> i recall seeing something about them wanting to reduce the 90 days even further
[16:04:58 CET] <flux> well, in practice it's a non-issue given its automated? with the 50 MB of software you don't want.. ;)
[16:05:10 CET] <flux> non-issue for this particular application I guess
[16:11:38 CET] <ubitux> so brightness, contrast and saturation are handled in swscale?
[16:11:59 CET] <ubitux> so we can integrate such adjustment within a scaler?
[16:12:09 CET] <ubitux> it doesn't look exposed to the filter
[16:21:38 CET] <wm4> dear god why does HEVC have/need captions
[16:21:57 CET] <ubitux> michaelni: do you confirm that yuv2rgb coeffs are 22 bits in sws?
[16:22:32 CET] <kierank> wm4: ?
[16:22:41 CET] <wm4> see ML
[16:22:46 CET] <kierank> I'm transcoding from h264 to hevc, how do I pass through my captions?
[16:22:47 CET] <kierank> etc
[16:22:52 CET] <kierank> yes saw that
[16:23:08 CET] <wm4> but why do you need HEVC if your hcain is rusty enough to require those captions
[16:23:11 CET] <wm4> *chain
[16:23:25 CET] <kierank> because it's mandatory in the USA
[16:23:27 CET] <kierank> by law
[16:23:34 CET] <kierank> to deliver closed captioning
[16:23:37 CET] Action: wm4 drops jaw
[16:24:51 CET] <funman> wm4: you mean you'd rather see dvb subs?
[16:25:11 CET] <wm4> I'm just asking for a small bit of sanity
[16:25:44 CET] <nevcairiel> you should find a new area to work in =p
[16:27:15 CET] <wm4> like what? web development?
[16:31:00 CET] <rcombs> kierank: and they have to be within the video bitstream?
[16:31:11 CET] <rcombs> instead of as a separate stream like a civilized system?
[16:31:40 CET] <nevcairiel> thats the correct way to transport them in broadcasts, yes
[16:31:50 CET] <rcombs> :|
[16:31:53 CET] <rcombs> why even
[16:32:00 CET] <rcombs> how does that make any sense
[16:32:22 CET] <wm4> it's like a modern version of teletext
[16:32:34 CET] <wm4> a hack to get it in somehow
[16:34:06 CET] <michaelni> ubitux, i dont think they are in SIMD code, that would be rather inefficient with >16bit coeffs
[16:35:08 CET] <ubitux> what coeffs are we supposed to use in simd code then?
[16:39:41 CET] <funman> rcombs: so the captions can be embedded in the video signal when transported over SDI
[16:42:43 CET] <rcombs> I thought SDI was always uncompressed?
[16:45:19 CET] <funman> yes it's uncompressed
[16:46:20 CET] <funman> but there's still room for side data associated to each frame
[16:46:37 CET] <funman> same model than within h264 or hevc rather than a separate stream independant from video track
[16:48:12 CET] <kierank> in the video frame it's much easier to handle
[16:48:19 CET] <kierank> but you need to reserve data for vbv
[16:48:49 CET] <kierank> I don't really know why they did it like that, perhaps to simplify hardware implementation in mpeg2
[16:50:22 CET] <michaelni> ubitux, for what efficient simd instructions exist, that is what fits in int16_t, thats whats used currently IIRC
[17:48:43 CET] <kierank> [Slack] Audio/Video Encoding Community xnJ˜D (Invitation to Audio / Video Encoding Community)
[17:48:51 CET] <kierank> I feel like I've been invited to bildenberg
[17:48:59 CET] <kierank> bilderberg*
[17:50:48 CET] <nevcairiel> i got that as well the other day
[17:50:52 CET] <JEEB> lol
[17:50:58 CET] <nevcairiel> it said "if you dont understand japanese, just ignore this"
[17:51:00 CET] <JEEB> shion keeps spamming that thing
[17:51:00 CET] <nevcairiel> so i did
[17:52:49 CET] <durandal_1707> put on blacklist
[18:25:05 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:3692d859f45f: avformat/mpegts: Only start probing data streams within probe_packets
[19:14:13 CET] <philipl> BtbN: so where to begin on the nvenc patches.
[19:15:24 CET] <philipl> I assume a serious response would be something along the lines of needing to define proper frame formats for cuda data and put the scaling portion in swscale.
[19:16:21 CET] <wm4> add cude to swscale?
[19:16:25 CET] <wm4> *cuda
[19:17:17 CET] <philipl> Well, presumably you don't want the encoder doing its own scaling right? Or do you?
[19:18:25 CET] <philipl> At least conceptually, you want to cuda data as a format right? Which you either support or don't support. Like the hwaccel output formats.
[19:19:16 CET] <philipl> and then you'd say cuda scaling is just a scaling algorithm that supports cuda formats for input and output.
[19:19:55 CET] <philipl> and the you wave your hands and can imagine using vdpau/cuda interop to make the hwaccel able to output cuda data straight into nvenc for transcode.
[19:20:17 CET] <philipl> (or dx/cuda interop as appropriate)
[20:48:03 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:c9bfd6a8c35a: libavutil/channel_layout: Check strtol*() for failure
[21:51:56 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:d4a731b84a08: avcodec/faxcompr: Add missing runs check in decode_uncompressed()
[00:00:00 CET] --- Fri Nov  6 2015