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

[burek]

[00:36] <cone-202> ffmpeg.git 03Michael Niedermayer 07master:8d7d88135cf3: avformat/mpeg: Avoid dead assignment
[00:36] <cone-202> ffmpeg.git 03Michael Niedermayer 07master:f2e12f8942e5: avformat/smoothstreamingenc: Add missing "goto fail"
[02:02] <cone-202> ffmpeg.git 03Hendrik Leppkes 07master:a9d700f2127f: mpegts: identify h264 mvc streams
[13:53] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:2493558a0640: avcodec/svq3: Check av_mallocs return value
[13:53] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:e6f1601d6d51: avcodec/svq3: Use av_mallocz_array() for emu_edge_buffer
[13:53] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:c4f1abecb15e: avcodec/sunrast: Use av_malloc_array()
[13:55] <compn> wm4 / Daemon404 : that bug 4260 is proof people are using mplayer filters in production work. although why anyone would use a denoiser on production video i have no idea haha :D
[14:01] <kierank> compn: yes I had a user using hqdn3d on 100 tv channels
[14:02] <wm4> 100?
[14:04] <Daemon404> hqdn3d is kinda crap as far as denoisers go
[14:04] <Daemon404> i thought people atopped uaing it 10 years ago
[14:04] <kierank> wm4: yes
[14:05] <kierank> it's crap but it's fast
[14:09] <compn> just annoying when people say how useless the filters are when users are already using them! :P
[14:09] <compn> then months later, try the 'oh , no ones using the filters (by evidence of some dev saying it over and over like if you repeat a lie often enough it becomes truth), so lets rm them'
[14:10] <Daemon404> people using mplayer in prod probably dont know any better and found tutoriala from 2003
[14:10] <compn> i'm talking the filters that are in ffmpeg from mplayer. not mplayer
[14:10] <Daemon404> the only ones left are like pp
[14:11] <Daemon404> which is literally hitler
[14:11] <compn> is that the entropy one ? :)
[14:11] <wm4> Daemon404: wrong
[14:11] <wm4> Daemon404: only 4 filters left in libmpcodecs
[14:11] <wm4> the others were ported
[14:12] <compn> i'm not talking about the port either, but iirc some dev said he thought the ported filters werent even being used
[14:12] <wm4> left are: vf_eq, vf_eq2, vf_ilpack, vf_softpulldown
[14:12] <compn> we need to do a ffmpeg survey on used features
[14:12] <compn> see what people are using.
[14:12] <Daemon404> ilpack is superseeded by swscale now isnt it?
[14:13] <wm4> also, even Libav has vf_hqdn3d
[14:13] <wm4> so it might be an "often used" filter
[14:13] <compn> whoa ;p
[14:13] <wm4> Daemon404: yes
[14:13] <Daemon404> its one of those filters everyone in fossland uses because nothing else wqs ported or rices
[14:13] <Daemon404> like yadif
[14:14] <compn> yeah where is that ffmpeg vaporsynth wrapper....
[14:14] <Daemon404> in mpv
[14:15] <Daemon404> wm4 wrote one ;)
[14:15] <compn> needs to be in ffmpeg so people can use 'teh best filters zomg'
[14:15] <Daemon404> i indeed use qtgmc on linux to deint
[14:16] <kierank> Daemon404: superceded by vf_scale yes
[14:16] <Daemon404> yea
[14:16] <compn> wm4 : reading libav git, hqdn3d was ported in 2010, before the split.
[14:17] <Daemon404> ita fine, nobody uses libav's lavfi
[14:17] Action: Daemon404 runs
[14:17] <iive> what happened with setting vf_scale interlace to auto?
[14:21] <kierank> Daemon404: +!
[14:21] <kierank> +1
[14:21] <kierank> Daemon404: what do you hate about mpeg-ts
[14:22] <compn> i think we need an mpegts developer , seems like theres lots of complaints about mpegts
[14:22] <compn> over the years, maybe it has changed ?
[14:22] <kierank> over the years ffmpeg supports more broken crap so mpegts will never work to the spec
[14:24] <compn> then a seperate mpegts demuxer that only follows the spec, perhapse ?
[14:24] <compn> or a wrapper around a lib that does that?
[14:25] <kierank> the demux is ok
[14:25] <compn> how about a wrapper lib kierank ?
[14:25] <kierank> the mux sucks
[14:25] <compn> er muxer then
[14:25] <kierank> wrapper lib won't stop the garbage input
[14:25] <compn> yes it will reject any non-standard
[14:26] <kierank> impossible to check
[14:26] <compn> "vp6 in mpegts? nope! denied! use -f ffmpegts instead"
[14:26] <compn> impossible eh
[14:27] <compn> i believe you, just looking for solutions.
[14:32] <saste> is there any way to avoid the padding requirement on the avcodec_decode_video2() input buffer?
[14:32] <saste> for example what if the buffer comes from the network, and is not padded? do we need to pad it (and memcpy it) anyway?
[14:34] <Daemon404> kierank, interpolated timestamps
[14:34] <kierank> Daemon404: hahaha
[14:34] <kierank> well it's cfr, who cares
[14:34] <kierank> not really interpolated
[14:35] <Daemon404> also, lavf doesnt get the correct timestamps if you dont call find_stream_info (i was not, since i didn ot need it)
[14:35] <wm4> saste: all I ever got was a inconclusive answer
[14:35] <Daemon404> some init stuff is hidden in it
[14:35] <Daemon404> but that's lavf being shit
[14:35] <compn> oh also microsoft writing ffmpeg build documentation on -devel list. didnt think i'd see that
[14:35] <wm4> bad documentation
[14:35] <saste> wm4, where did you ask? here on on list?
[14:36] <wm4> saste: I asked michaelni 
[14:36] <compn> wm4 : its microsoft, thats implied
[14:36] <wm4> saste: probably both on irc and on the list
[14:36] <Daemon404> compn, they emailed oen of us saying how they "ported" it to msvc via finding the correct configure flags
[14:36] <Daemon404> as if there wasnt a masive amount of effort from us to port it over the last 2 years
[14:36] Action: Daemon404 just fff'd
[14:36] <wm4> apparently the padding is not "required", except sometimes in mysterious circumstances, and bugs
[14:37] <compn> Daemon404 : lol. well , theres some cognative dissonance going on, microsoft supporting open source tools because a large portion of their users want msvc to build ffmpeg.
[14:37] <Daemon404> ms has steadily been going FOSS lately
[14:37] <Daemon404> the entire c# and .net toolchain is open source now
[14:37] <Daemon404> and they are the biggest contributer to libgit2
[14:37] <Daemon404> etc
[14:38] <saste> wm4, only mention I found by googling: http://tdistler.com/2011/01/06/ffmpeg-and-invalid-buffer-reads
[14:38] <compn> yeah , they really turned around . i know they are sending crash reports to vlc and stuff
[14:38] <Daemon404> compn, and theyre better at FOSS than google right now.
[14:38] Action: compn stops interrupting buffer discussion
[14:38] <Daemon404> as in they actually respond
[14:38] <Daemon404> and not just dump code
[14:39] <compn> if anyone has a good open source microsoft contact, i'd like to have that email so i can ask some questions.
[14:39] <nevcairiel> dont give it to him, he'll just piss them off :p
[14:39] <compn> maybe a contact at bing
[14:40] <compn> lol!
[14:41] Action: compn wonders if he pisses nevcairiel off
[14:50] <__gb__> compn, gaby is one such instance
[14:50] <__gb__> there are others I lost track off though
[14:57] <compn> ehe j-b trolling the libyami intel guy 
[14:57] <wm4> intel deserves it
[15:02] <compn> wm4 : do you know if vaapi , when it does crash, does it take the whole gpu with it? and if so, do you think this libyami api will crash in a ... not so destructive crash aka allow the gpu to recover ?
[15:02] <compn> i havent used vaapi so i dunno its crashing behavior
[15:04] <wm4> I haven't used vaapi either
[15:05] <__gb__> gpu hang recovery is a kernel feature, it
[15:05] <__gb__> it's up to the sw layer to bubble up errors accordingly...
[15:05] <compn> blurgh
[15:05] <compn> so fail in the worst way possible then :)
[15:09] <__gb__> on one hand, I am glad that any user can now use the GPU media engines through DRM render nodes without specific privileges, on the other hand, it's quite easy to craft gpu hangs, driver, or better, kernel driver needs to ensure/robustify certain command streams
[15:09] <wm4> this is why anything with gpus is shit
[15:09] <__gb__> there is WIP for the other case in the kernel space iirc
[15:09] <wm4> they apparently crash quite easily, and drivers are then supposed to verify commands to prevent this
[15:09] <wm4> which just doesn't work
[15:10] <__gb__> or, stated differently, is generally not implemented
[15:10] <__gb__> for performance reasons, unless you employ clever tricks
[15:13] <wm4> wait, security mechanisms are not implemented for performance reasons?
[15:16] <rcombs> that's some quality prioritization right there
[15:17] <iive> the problem is that the hardware is full of bugs and almost never fixed.
[15:17] <iive> also gpu hang is not security issue, cannot exploit it... the cpu should be able to reboot it.
[15:18] <__gb__> iive, DoS is the issue even if you can't exploit
[15:19] <nevcairiel> at least on windows it reached a state where you can only crash the driver, but not the OS, it'll recover
[15:20] <nevcairiel> well, at least on nvidia or intel, i have a reproducable case to bluescreen AMD :P
[15:20] <iive> sure, but it won't affect the rest of the system, you will only wonder why your screen goes dark (hopefully for a while)
[15:22] <__gb__> yes, but this remains terrible or fatal inconvenience to users
[15:23] <__gb__> in terms of exploits, I don't know any on intel/amd/nvidia, though I think I read something for mali or powervr on select systems
[15:29] <compn> its probably going to be bad when gpu malware comes out
[15:34] <iive> uefi one is bigger concern.
[17:52] <kierank> wtf
[17:52] <kierank>  avcodec: Allow user applications to provide non padded input buffers
[17:53] <kierank> api break?
[17:53] <nevcairiel> i think you should  rather yell at user apps that try that
[17:54] <wm4> kierank: doesn't look like an API break...
[17:56] <wm4> nevcairiel: how?
[17:56] <nevcairiel> dunno, the same condition that he wants to use to detect missing padding? :d
[17:57] <wm4> hmmm
[20:03] <j-b> compn: trolling? come on.
[20:04] <j-b> compn: I have experience with intel libraries
[20:04] <j-b> they are utter shit
[20:04] <j-b> and break all the time
[20:06] <compn> j-b : in the context of adding features to vaapi support, i'm curious about your alternatives. while your concerns may be valid, the alternative is not great
[20:07] <compn> s/may be/are
[20:08] <j-b> compn: sorry what?
[20:09] <j-b> the alternative is to add encoding support to the vaapi files.
[20:09] <compn> for us to maintain that and not intel ?
[20:10] <j-b> sure.
[20:10] <compn> we dont have the devs nor hardware afaik
[20:10] <j-b> bullshit
[20:10] <j-b> there is no hardware at all for VP8 and VP9 encoders
[20:10] <compn> intels making it now, apparently
[20:10] <j-b> and all the current Intel chips do h264 and jpeg encoding
[20:11] <compn> or some kind of extensable offloading of codec features, or something
[20:11] <compn> so you are saying we should build our own hw h264 encoder ?
[20:11] <compn> :P
[20:11] <j-b> yes
[20:11] <j-b> the API is there
[20:11] <compn> this after the whole x264 debacle
[20:12] <j-b> compn: are you dense?
[20:12] <compn> yes.
[20:12] <j-b> ok, that explains
[20:12] <j-b> VAAPI is a public API
[20:12] <j-b> that already exists
[20:12] <j-b> that you already use
[20:12] <j-b> that does decoding and encoding
[20:12] <compn> j-b : how do you test hwaccel on various systems ? i dont think ffmpeg has a way to do it yet, just curious if vlc runs any ?
[20:12] <j-b> you just need to hook up the encoding part
[20:13] <j-b> it's probably a simple task.
[20:13] <j-b> noone said that you should do your own encoder
[20:13] <j-b> vaapi is already a front-end to various encoders and decoders of the intel chips
[20:13] <j-b> So you want to use a front-end to a front-end?
[20:13] <compn> i know, i was just making a joke there. my bad
[20:14] <compn> >another h264 encoder :P
[20:14] <compn> ehe
[20:14] <j-b> a1m
[20:14] Last message repeated 1 time(s).
[20:14] <compn> cant remember if crystalhd chip had an encoder or not
[20:14] <j-b> it has not
[20:15] <j-b> FFmpeg used to be the ones removing all external libraries because the internal code is better
[20:15] <j-b> and now there is this new fetichism of doing the total opposite.
[20:15] <compn> ffmpeg also used to pull in all external libs to make a generic api for all of them
[20:16] <compn> which is older than the removing external libs fetish
[20:16] <j-b> almost every other API is simpler than FFmpeg...
[20:16] <compn> i dunno which is better...
[20:16] <compn> i dont run the project .
[20:16] <j-b> Anyway, do as you wish, not my problem.
[20:17] <ubitux> he's not going to do anything :)
[20:17] <compn> the ffmpeg vaapi code was written by splitted-desktop it looks like
[20:17] <ubitux> i agree with not encouraging this lib thing
[20:17] <j-b> but seeing the stagefright experience, this is a very bad idea
[20:18] <j-b> and this thning does even more replicating ffmpeg code
[20:18] <j-b> and I don't even speak of libavcodec calling libyami calling libavformat calling libavcodec
[20:20] <compn> hehe
[20:21] <compn> oh thats gwenole
[20:21] <compn> __gb__ : what do you think about libyami? :P
[20:21] <compn> (who committed vaapi stuff)
[20:22] <kierank> j-b: have you not figured out by now ffmpeg will just merge any old crap
[20:22] <kierank> I mean I could write assembly for an imaginary CPU in my head and it'll get applied
[20:23] <compn> as long as you also write the fate test kierank
[20:23] <j-b> kierank: you have a big brain :)
[20:23] <compn> must have fate test.
[20:23] <kierank> I am going to fork fate soon 
[20:23] <compn> for the better or just for nih ?
[20:23] <kierank> a fate that  tests the api
[20:24] <kierank> rm -rf ffmpeg.c
[20:24] <compn> oh good then.
[20:24] <kierank> i am certain very little will work
[20:24] <kierank> lavc will probably be ok
[20:24] <compn> kierank : can you also add benchmarking to it ? so we can see if thing speeds up or slows down over time :P
[20:24] <kierank> lavf on the other hand
[20:24] <compn> just a little timer on each test 
[20:24] <compn> nothing too complicated.
[20:24] <kierank> the noise would be too large for most things
[20:25] <compn> bah
[20:25] <compn> then compare each run's timers
[20:25] <compn> i guess for api, benchmarks dont matter much
[20:26] <kierank> ffmpeg.c is the new mplayer
[20:27] <kierank> it needs to die
[20:28] <compn> i agree it would be nice to split ffmpeg.c from the other libs
[20:29] <compn> but theres nothing stopping you from making the libs more independent now, is there ?
[20:29] <kierank> no but the tests should be on the libs
[20:29] <kierank> not on ffmpeg
[20:29] <ubitux> there are some
[20:29] <ubitux> you need a -test tool like there are many
[20:29] <kierank> i know
[20:29] <compn> so are you just going to take c code from other projects (that use the api) or are you going to make new code snippets for testing? just curious
[20:30] <kierank> use the examples
[20:30] <compn> huhuhuh :D
[20:30] <kierank> are you really suggesting to me the examples are useless =p?
[20:31] <compn> no , but real world example are good too
[20:31] <compn> anyways gotta run 
[20:31] <compn> sorry for being dense :P
[21:05] <cone-975> ffmpeg.git 03Paul B Mahol 07master:baea14d86021: avfilter: port qp filter from libmpcodecs
[21:05] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:3cfd07a53fd9: fate: add qp filter test
[21:19] <Daemon404> [FFmpeg-devel] Adding Webvtt in hls muxer
[21:19] <Daemon404> j-b will surely be pleased
[21:20] <j-b> well, it's a bad format, but it's a format
[21:20] <Daemon404> hls or webvtt? ;)
[21:27] <j-b> both actually
[21:27] <Daemon404> exactly
[21:42] <wm4> and of course no demuxer
[21:42] <wm4> this kind of stuff is very bad for ffmpeg in the long range
[21:42] <wm4> because some still like to use it for demuxing and decoding
[21:44] <wm4> there should be a policy that nothing should be added to encoding if ffmpeg can't decode it, but I guess the project leadership doesn't have the balls to enforce something like this
[21:45] <kierank> "project leadership"
[21:45] <kierank> lol
[21:48] <j-b> wm4: and one that it should not be added to encoding, if it does not fit the spec?
[21:48] <wm4> yes
[21:48] <iive> why enforce policy?
[21:48] <iive> isn't common sense enough?
[21:49] <j-b> common sense does not exist
[21:49] <wm4> and forced trepanation if someone makes ffmpeg produce broken files
[21:49] <iive> well, it does. but is not so common.
[21:49] <j-b> then it does not :)
[21:49] <j-b> or the common part is so reduced it makes no sense
[21:50] <iive> that's the joke ;)
[21:50] <j-b> Voltaire, no?
[21:51] <iive> yes
[22:00] <compn> wm4 : why care about ffmpeg producing bad files? :P
[22:00] <compn> but yes good policy
[22:29] <wm4> "Yes, it was my intention to do it for every external lib. "
[22:29] <wm4> god help us
[22:29] <wm4> (manual dynamic loading of dlls)
[22:30] <JEEB> lol
[22:34] <j-b> what's the use case?
[22:34] <j-b> once agin...
[22:37] <jamrial> wm4: we can mux animated webp, but not decode/demux the resulting files
[23:11] <michaelni> wm4, i do want demuxing and decoding support for everything we support muxing and encoding
[23:12] <michaelni> actually i also want muxing and encoding support for everything for which we support decoding and demuxing
[23:13] <michaelni> it feels wrong to me though to make it a requirement that a volunteer contributor implements all this
[23:16] <michaelni> besides, has anyone asked the patch author, maybe he wants to implement the other direction anyway ?
[23:28] <kierank> 9:34 PM <"j-b> what's the use case? --> windows I guess
[23:32] <j-b> no
[23:34] <nevcairiel> on windows you just distribute your own binary package anyway
[23:34] <nevcairiel> so its not all that useful
[23:37] <j-b> exactly
[23:39] <nevcairiel> could more see it for a binary linux distro that doesnt want to add a million harddeps when just installing avcodec
[23:39] <nevcairiel> but thats still somewhat limited usefulness
[23:40] <j-b> statically link them
[23:40] <j-b> it makes sense for non-open source components or for componnents that have different ABIs depending on th OS version
[00:00] --- Thu Jan 15 2015