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

[burek]

[00:43] <cone-561> ffmpeg 03Andreas Cadhalpun 07master:5de2dab12b95: avcodec/webp: validate the distance prefix code
[00:55] <nevcairiel> suprising news with gsoc
[00:56] <kierank> yeah
[00:57] <nevcairiel> and people said its not even worth applying
[00:59] <jamrial> after like four failed attempts and the rumors of a ban i can see why people were pessimistic
[01:05] <kierank> I take all my trolls back
[01:06] <kierank> now hopefully gsoc can make progress
[01:08] <nevcairiel> while i don't have time to really mentor anyone, I'm at least usually here to answer questions for the students
[01:09] <Daemon404> i mentored one year, and my student passed, and i still havent recieved the tshirt
[03:32] <Timothy_Gu> we should write a news article about GSoC
[03:39] <compn> 'ffmpeg is in gsoc for 2015. sign up here (link)'
[10:15] <saste> ramiro, you going to act as mentor for gsoc?
[10:15] <ramiro> yes
[10:17] <ramiro> I'm also thinking about a project involving cataloging and reverse-engineering more fringe game codecs, like mike used to do.
[10:18] <saste> ramiro, oh ok, just reading the wiki page
[10:19] <thardin> ramiro: any specific games in mind?
[10:20] <ramiro> thardin: no. just any old game
[10:20] <ramiro> do you have any suggestions? =)
[10:22] <thardin> neverhood maybe? :)
[10:23] <thardin> or better yet: some game scummvm doesn't support
[10:23] <thardin> maybe some FMV game, like phantasmagoria
[11:18] <mintoo_> hi ,there
[11:18] <mintoo_> i am gsoc 2015 aspirant.
[11:18] <mintoo_> i want to know more about Animated Portable Network Graphics (APNG) 
[11:29] <xxthink> how to enable av_dlog macro?
[11:46] <saste> xxthink, #define DEBUG 1
[11:46] <saste> before the header which defines av_dlog()
[12:14] <cone-226> ffmpeg 03Robert Krüger 07master:618021ea58cd: avformat/mxfenc: adjust product name when opatom muxer is used
[13:06] <michaelni> mintoo_, great, would be best if you contact paul per email, he seems not on IRC atm
[13:13] <cone-226> ffmpeg 03Andreas Cadhalpun 07master:2578a546183d: avcodec/rv10: check size of s->mb_width * s->mb_height
[13:26] <gabor> Hey I am new to your organisation and I am interested in VDPAU filter. I was wondering if I could get the relevant literature for the same :) 
[13:29] <j-b> michaelni: can you look at the VP9 patch sent? It's a big issue for VLC on Windows.
[13:30] <michaelni> j-b, will do in a moment, just need to finish a mail iam writing
[13:31] Action: michaelni looks around, sees no BBB 
[13:33] <nevcairiel> all avcodec video decoders always consume the entire frame you pass to it, and that assumption is also how nearly all code that uses avcodec is implemented, so it happens that such a problem is not caught, and the best choice would probably to also assume this in vlc if you want to avoid problems from that :d
[13:41] <wm4> gabor: I wonder what's the point of such a filter at all
[13:42] <wm4> nevcairiel: yeah, the API still should return the packet size, but by now caller shouldn't do the incremental decoding thing for video
[13:42] <wm4> also why would this be windows specific?
[13:42] <nevcairiel> dunno
[13:42] <nevcairiel> maybe linux uses libav?
[13:42] <nevcairiel> depending on the OS its on, i guess
[13:43] <wm4> lol
[13:43] <nevcairiel> s/OS/distribution/
[13:43] Action: Daemon404 still has incremental decoding loop
[13:43] <Daemon404> :x
[13:43] <wm4> I can see this happening
[13:43] <nevcairiel> Daemon404: i removed mine for video as there were 1-2 other codecs that caused problems and i cba to fix them
[13:44] <Daemon404> \Ë/
[13:44] <nevcairiel> but i use threaded decoding for vp9, so the problem doesnt appear
[13:44] <nevcairiel> curious that vlc doesnt use frame-threads for vp9
[13:44] <nevcairiel> but oh well
[13:47] <pross> concerning gsoc: do we have enough qualification tasks? more needed?
[13:48] <michaelni> more qualification tasks surely cant hurt also ideally qual tasks should be related to the project a student would be working on in the summer
[13:48] <leandrosansilva> Hello, I'm using libavcodec to encode videos (using VP8 codec) and I'd like to know if there is a way to preallocate the AVPacket used on avcodec_encode_video2 call so it will not be allocated for each frame I encode. What I need is basically allocate it only once and then use the same across the encoding process.
[13:49] <gabor> wm4: umm.. i was talking about the VDPAU filter gsoc project.. 
[13:49] <cone-226> ffmpeg 03Steve Lhomme 07master:4851db80a4f8: fix VP9 packet decoder returning 0 instead of the used data size
[13:50] <michaelni> j-b, applied
[13:51] <wm4> gabor: yes, and I don't see how much sense it makes... because vdpau only has one big function, which does yuv->rgb _and_ some additional filtering
[14:02] <nevcairiel> leandrosansilva: thats not supported for avpackets
[14:05] <nevcairiel> leandrosansilva: it does appear it does this internally however, for vp8 anyway, it has an internal byte buffer that it re-uses
[14:07] <leandrosansilva> So, AVPacket->data points to this internal buffer?
[14:07] <nevcairiel> it appears so
[14:07] <wm4> isn't that for decoding?
[14:08] <nevcairiel> it uses ff_alloc_packet2, which uses avctx->internal->byte_buffer
[14:08] <cone-226> ffmpeg 03Claudio Freire 07master:6394acaf36da: AAC: Fix M/S stereo encoding
[14:09] <nevcairiel> it might even work  if you simply pre-allocate the AVPacket and pass that into the encode API
[14:09] <nevcairiel> it doesnt work with all encoders, but it might work for vp8 judging from the code
[14:09] <nevcairiel> although you need to make sure its big enough
[14:10] <nevcairiel> but if all you want is to ensure there arent needless allocations, might as well trust avcodec to do the right thing
[14:14] <leandrosansilva> I got it
[14:17] <leandrosansilva> Currently before encoding each frame I call av_init_packet and after using it, I call av_free_packet.  Looking at those functions's code, They do not allocate neither desallocate memory, which sounds good. I just 'd like to to ensure I'm not doing unneeded allocations
[14:18] <nevcairiel> assuming the buffer doesnt need to be resized, you could simply print the pointer in avpkt->data to check if it remains the smae
[14:18] <nevcairiel> it might change in the beginning a few times as the buffer is resized, but eventually it should remain the same
[14:18] <leandrosansilva> nevcairiel: excellent idea :-)
[14:19] <leandrosansilva> thx
[14:20] <wm4> what is it with rtp and requiring so much codec specific code?
[14:21] <nevcairiel> the format is just like that
[14:26] <akshay_> Hey, This is Akshay and I would like to work on "Basic servers for network protocols" listed under gsoc 2015.
[14:30] <akshay_> I under what avformat does and what this project demands me to do.
[14:32] <akshay_> But I am not able to reach reynaldo
[14:40] <akshay_> Please reply.
[14:44] <j-b> michaelni: thx
[14:49] <ubitux> so what's the explanation for why vlc was affected by this bug and not the other?
[14:49] <ubitux> can't have tests to detect such bug?
[14:49] <compn> akshay_ : wait around here for an answer, its early still :)
[14:49] <ubitux> +we
[14:51] <compn> gabor : did you read the vdpau api yet ?
[14:51] <compn> http://http.download.nvidia.com/XFree86/vdpau/doxygen/html/ 
[14:51] <compn> i think
[14:52] <wm4> hm can we add Dash demuxing support to gsoc?
[14:52] <Daemon404> "demuxing"
[14:53] <wm4> whatever you call it
[14:53] <compn> wm4 : add it as unmentored project at the end of the trac page, unless you also want to mentor it...
[14:53] <Daemon404> i fear the results of that
[14:53] <Daemon404> libavxml
[14:53] <wm4> lol
[14:53] <compn> gabor : and then the qualification task calls for writing an inverse telecine video filter, so you will have to read up on inverse telecine 
[14:53] <ubitux> no need for that, we already have ff_smil_* functions :s
[14:53] <ubitux> compn: what
[14:54] <ubitux> don't we already have at least 2 ivtc filters?
[14:54] <Daemon404> thats what you get for not updating the qual tasks fory ears
[14:55] <JEEBsv> ubitux: I think you had some ideas on playlist/virtual timeline stuff for lavf?
[14:55] <ubitux> mmh
[14:55] <ubitux> i have a patchset for mov timeline, but that's all
[14:55] <ubitux> i should apply but&
[14:55] <ubitux> i got no review so a bit uncomfortable
[14:55] <JEEBsv> there's seemingly a GSoC thing for that in XBMC and I'd see more usefulness in making a general FFmpeg solution for that
[14:56] <compn> ubitux : i didnt write the vdpau filter qual task idea
[14:56] <compn> ubitux : so if you have a better qual task for vdpau filter, please edit the gsoc page
[14:56] <compn> ubitux : https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015#VDPAUfilter
[14:56] <compn> and i guess talk to carl first ;)
[14:57] <ubitux> JEEBsv: patchset is here http://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167317.html
[14:57] <ubitux> i think that's the last patchset i sent
[14:57] <JEEBsv> k
[14:57] <compn> wm4 : do you have a trac login? you want me to write in your project idea ?
[14:58] <compn> love it or hate it fellow developers, we're in gsoc this year and we should probably work together to get it streamlined now haha
[14:58] <ubitux> compn: yeah i dunno, i don't really care about the gsoc logistic :p
[14:59] <compn> ubitux : is there a better filter you would like implemented ?
[14:59] <compn> i mean, we may have many students and more qual tasks are useful.
[14:59] <compn> because two can compete 
[14:59] <compn> (or three, four)
[14:59] <compn> and it sucks if they have to work on the same filter
[14:59] <ubitux> compn: no, i'd prefer if we improve those we have
[15:00] <ubitux> the only remaining filters to do are mainly huge work
[15:00] <ubitux> so either we find a skilled student working on it for months, i don't see anything
[15:00] <compn> wm4 keeps complaining we arent porting "good" filters, maybe he has a suggestion for porting a specific filter from another open source project ?
[15:00] <ubitux> if we do, yeah motion comp stuff for various usages
[15:00] <ubitux> typically.
[15:00] <ubitux> or API changes
[15:01] <compn> wm4 : any suggestions on filters you want to see in ffmpeg ?
[15:01] <ubitux> most of our current limitations are due to api limitations
[15:01] <ubitux> compn: "vapoursynth" stuff
[15:01] <compn> ubitux : making a student work on api probably isnt good idea
[15:01] <ubitux> compn: porting is one thing, maintaining them in another one
[15:01] <ubitux> compn: i know
[15:01] <ubitux> that's why i don't have anything to give
[15:01] <compn> ok no worries, thanks for input :)
[15:02] <ubitux> we have more filters than formats
[15:02] <ubitux> a lot of filters have dubious quality, i'd better have those improved
[15:02] <compn> asking a student to run double blind tests and experiment on filters seems hard too.
[15:02] <ubitux> i mean we have a shitload of stuff to do, but most of it requires a lot of work
[15:02] <compn> but a possibility
[15:02] <compn> yea
[15:03] <compn> ffmpeg is not an easy project to work on :)
[15:03] <ubitux> as you can guess, most of us already picked the cool fun things
[15:03] <ubitux> i actually think that the most simpler would be to add optimizations
[15:03] <ubitux> i mean so many of our filters could benefit from asm
[15:03] <ubitux> and there are many codecs and places where we can add arm support typically
[15:04] <ubitux> it's very easy to find something we asm would be welcome
[15:04] <ubitux> where*
[15:04] <ubitux> http://trac.ffmpeg.org/ticket/3921 random example
[15:04] <wm4> time to remove compn from the ignore list
[15:04] <compn> right , that could be an entire gsoc project, making arm or asm optimizations for various parts 
[15:04] <ubitux> wm4: he's just asking for filters you want implemented
[15:04] <compn> now we just need a mentor ;)
[15:05] <ubitux> compn: why don't you?
[15:05] <kurosu_> there's a task on post processing, which is a filter
[15:05] <compn> shhh dont give anyone any ideas :)
[15:05] <ubitux> kurosu_: yeah but that's probably one of the least useful one
[15:05] <kurosu_> mentoring asm can probably be done by a lot of people in here
[15:05] <compn> also i dont have time i can dedicate i dont think.
[15:06] <poste9> whats up it those #if 1 at the ffmpeg.c ?oO
[15:06] <compn> poste9 : debug maybe ?
[15:06] <ubitux> it's to be sure to have the code compiled ;)
[15:06] <gabor> :compn will do! Thanks for the help
[15:06] <ubitux> poste9: easily disablable code :p
[15:07] <kurosu_> ubitux, because everything is h264 nowadays? I think this has been the most used one, actually
[15:07] <ubitux> also often with a "#else" to try another approach
[15:07] <compn> kurosu_ : yes, and arm probably only requires someone with ssh access to an arm box to test patches and run benchmarks
[15:07] <poste9> yep, I just thought it wasnt supposed to be commited but w/e
[15:07] <kurosu_> compn, and that knows arm, which is a lot less people than x86
[15:07] <poste9> my bad
[15:07] <ubitux> kurosu_: codecs are not the only place where you can add asm
[15:07] <ubitux> kurosu_: look at the filters&
[15:07] <ubitux> and the scalers
[15:07] <compn> kurosu_ : well if its bit exact and faster , do you really need to know the code?
[15:07] <kurosu_> ubitux, did I say anything like that? I think you misunderstood me
[15:08] <nevcairiel> compn: you do
[15:08] <ubitux> kurosu_: what are you answering to then?
[15:08] <ubitux> i probably misunderstood indeed :)
[15:08] <kurosu_> ubitux, to the fact that pp is a filter
[15:09] <compn> ubitux  : i think kurosu_ is saying that postproc is for h263 and most files are h264 now thus making postproc obsolete ?
[15:09] <compn> or someone said that before
[15:09] <kurosu_> I think as something postprocessing the image outside of a codec, it is more used than any other one, but true that it is tied to codecs
[15:09] Action: compn runs away with confusions
[15:09] Action: ubitux still very confused
[15:10] <kurosu_> more precisely I was replying to you saying "yeah but that's probably one of the least useful one" about pp
[15:10] <ubitux> aah
[15:10] <ubitux> well yeah because no one needs crazy optimizations for modern cpu 
[15:10] <ubitux> for old xvid videos
[15:11] <ubitux> i mean it's cool to have such optimizations for old cpu but nowadays i don't think it really matters
[15:11] <compn> do you really need optimizations for 4k video thats already been DNR'd to death ? :P
[15:11] <kurosu_> well, people mention how mpeg-2 is still alive and kicking
[15:11] <kurosu_> but anyway, I don't disagree
[15:12] <kurosu_> there's mmxext stuff already and going sse2 won't help on computers doing realtime already
[15:12] <wm4> this postproc stuff is ridiculous
[15:13] <ubitux> i think we would need faster scalers instead 
[15:13] <wm4> there are enough filters around that actually do improve video from modern sources, but ffmpeg has almost none of them
[15:13] <wm4> (hint: asvisynth)
[15:13] <wm4> *avisynth
[15:13] <ubitux> stuff like fast paths for rgb2rgb typically
[15:13] <wm4> oh and libswscale needs a rewrite
[15:13] <compn> wm4 : which avi synth filter do you want ported, or a wrapper for the whole thing ?
[15:13] <compn> can make students do both :)
[15:13] <wm4> compn: at this point I prefer using vapoursynth
[15:13] <ubitux> wm4: i don't think a "rewrite" is necessary
[15:14] <ubitux> wm4: the exposed api is mostly fine, isn't it? (aside from the missing AVFrame wrapper)
[15:14] <ubitux> aren't the main problems about the slow paths?
[15:14] <wm4> the API is... "fragmented"
[15:14] <ubitux> ;q
[15:15] <ubitux> oups
[15:15] <wm4> (at least 3 ways to setup libswscale)
[15:15] <ubitux> i don't remember issues with it last times i used it
[15:15] <wm4> but yeah I like to think that my AVFrame patch increases API friendlienss significantly
[15:16] <wm4> and libswscale internals are so terrible, not even seasoned ffmpeg devs want to touch it
[15:16] <wm4> and those who can touch it are not interested in clean, maintainable code anyway
[15:16] <kurosu_> wm4: so that's your reason for not doing it and instead lobbying others to do it ?
[15:16] <ubitux> my main complain about the exposed api are the flags
[15:17] <wm4> kurosu_: yes
[15:17] <kurosu_> ok
[15:17] <wm4> I probably should resend the AVFrame patch, though
[15:17] <ubitux> i don't really get how these flags are mixed typically
[15:17] <wm4> which ones?
[15:18] <wm4> it's odd that the flags select the scaler
[15:18] <ubitux> like some flags are exclusive
[15:18] <ubitux> you can't pick bicubic and bilinear, but you can add bitexact
[15:18] <ubitux> that kind of stuff
[15:18] <ubitux> and i'm annoyed by the dithering options too
[15:19] <ubitux> like, "auto" is mapped to 0 instead of "none" (recognized by default by avopt)
[15:19] <ubitux> and basically you can't disable the dithering, which is too bad sometimes
[15:22] <compn> carl is online just not on irc
[15:22] <compn> harumph
[15:24] <kurosu_> anyway, regarding lavfilters, I discussed a little while ago with a Netflix engineer, and basically, http://ffmpeg.org/pipermail/ffmpeg-devel/2012-October/132031.html still has a lot of valid points
[15:24] <wm4> yeah
[15:25] <kurosu_> note: I was never pointed at this mail, it was just a coincidence I read it recently too
[15:27] <Daemon404> oh hey
[15:27] <Daemon404> my email
[15:27] <Daemon404> <3
[15:27] <Daemon404> kurosu_, i think you and i may know the same engineer.
[15:27] <kurosu_> well, your company and Netflix are basically doing the same thing
[15:27] <kurosu_> Daemon404, actually maybe not, depends on the time frame ;-)
[15:27] <wm4> which is?
[15:28] <Daemon404> wm4, Arwen
[15:28] <Daemon404> kurosu_, everybody does distributed GOP encoding
[15:28] <Daemon404> it's not special
[15:28] <Daemon404> netflix is quite good at marketgeneering though
[15:29] <wm4> Daemon404: I mean the thing they do
[15:30] <Daemon404> aka distributed-GOP
[15:30] <Daemon404> we do it, youtube do, netflix does
[15:30] <Daemon404> probably hulu
[15:30] <wm4> and who has patented it?
[15:31] <Daemon404> youtube is trying to
[15:31] <Daemon404> but IMO it is overly vagye
[15:31] <Daemon404> vague*
[15:31] <Daemon404> simultaniously unenforcable
[15:31] <Daemon404> and x264farm is prior art
[18:26] <cone-226> ffmpeg 03Mark Reid 07master:81a91269a2fb: libavformat/avio: added avio_put_str16be
[18:33] <himangi> hey! I am a student from India and am interested in contributing to ffmpeg for GSoC this summers
[18:34] <himangi> I have gone through the GSoC page and found some interesting ideas..
[18:36] <himangi> particularly FFv1 P frame support is interesting to me.. I have been interested in video formats and encoding since my research at the university does involved working with videos. 
[18:37] <himangi> I see it is mentored by michaelni ... any help getting started with implementing the basic P frame support?
[18:41] <michaelni> himangi, take a look at libavcodec/ffv1*.c also https://github.com/FFmpeg/FFV1
[18:44] <himangi> michaelni, thanks.. I have been looking at the files and will have a look at the documentation :)
[20:11] <poste9> can somebody put 65535 as constant pls ? 
[20:13] <ramiro> poste9, it's the 0xFFFF constant
[20:13] <poste9> derp it is FLAC_MAX_BLOCKSIZE
[20:13] <ubitux> or UINT16_MAX
[20:14] <poste9> its just I saw this number and had no idea what it is
[20:14] <poste9> and Im pretty sure there are a lot of dump ppl like me
[20:14] <poste9> dumb*
[20:15] <poste9> like MAX_DEN_TIMEBASE or something like that
[20:16] <poste9> its on ffmpeg.c line 2853
[20:25] <cone-226> ffmpeg 03Clément BSsch 07master:c285937ccc98: ffmpeg: comment mpeg4 hack
[20:25] <ubitux> poste9: "fixed"
[20:28] <poste9> yea that will help, thanks ^^
[20:28] <llogan> maybe we should do something about those github pull requests. perhaps have it send to the ML if possible.
[20:28] <llogan> does anyone other than michael review them?
[20:29] <wm4> I doubt it
[20:29] <llogan> would anyone be against them showing up in the mailing list?
[20:29] <wm4> how? do you want to redirect github notifications to the ml?
[20:30] <llogan> i don't know how yet.
[20:31] <llogan> i don't know if there is a way to send just the pull requests an no other fluff
[20:31] <Daemon404> they have an api, you can do whatever you want
[20:32] <llogan> ok. i'm just thinking aloud here.
[20:32] <Daemon404> in general, PRs are people who couldnt even be arsed to take a cursory glance at how contribute
[20:33] <Daemon404> and thus tend to be quite poor quality
[20:38] <wm4> well, if github allowed to disable PRs, this would be simple
[20:39] <Daemon404> given the responses i got from their enterprise support, the impression i get of their codebase is that it's hard to do that
[20:40] <Daemon404> (because lulz)
[20:47] <poste9> isnt avcodec_copy_context supposed to copy the codec as well?
[20:49] <wm4> yes I think it is
[20:49] <wm4> at least my problem with this function was that you can't change the codec after copying, and the avcodec_alloc_context (or whatever) API also requires a codec
[20:51] <poste9> ffmpeg.c line 3054
[20:51] <poste9> then line 3060
[20:51] <poste9> it calls the copy_ctx function
[20:51] <poste9> then kinda "re-do" for codec 
[20:53] <cone-226> ffmpeg 03Vittorio Giovara 07master:e878ec0d47cd: aic: Fix decoding files with odd dimensions
[20:53] <cone-226> ffmpeg 03Michael Niedermayer 07master:75dbe4c1fa2c: Merge commit 'e878ec0d47cd6228c367b2f3128b76d7523f7255'
[20:54] <wm4> poste9: looks very broken
[20:54] <ubitux> 00dcb1063110fc417f4e98b3dad3479ed9d35eef
[20:55] <wm4> the codec requires private data to be allocated, that's why avcodec_alloc_context3 takes a codec parameter
[20:55] <wm4> ubitux: just as expected
[20:55] <wm4> some shitty hack to fix a cosmetic issue
[20:55] <llogan> ffapi
[20:59] <poste9> guys Im sorry if I say something stupid, I started coding in c++ like 2 months ago, and Im trying to make my own version of ffmpeg.c with only my needs... so Im looking around the code and talking about what looks weird
[20:59] <poste9> I just dont  wanna look like I think I know more than any of u
[21:01] <wm4> you successfully found an invalid API usage by ffmpeg.c already
[21:06] <Daemon404> as if thats hard
[21:16] <cone-226> ffmpeg 03Vittorio Giovara 07master:994d8f309518: fate: Add AIC test with odd sizes
[21:16] <cone-226> ffmpeg 03Michael Niedermayer 07master:b7d3fbc69bb6: Merge commit '994d8f3095180ba1b2c6040a97718e931a782b34'
[21:26] <cone-226> ffmpeg 03Vittorio Giovara 07master:0af3b6588057: asf: do not export XMP metadata by default
[21:26] <cone-226> ffmpeg 03Michael Niedermayer 07master:0dd53e14f968: Merge commit '0af3b65880573aa9b3375362eaab4f84140c7dde'
[22:40] <cone-226> ffmpeg 03James Cowgill 07master:de4f59b53672: mips: use float* to hold pointer instead of int
[22:40] <cone-226> ffmpeg 03James Cowgill 07master:37ffe7f90a57: mips/aaccoder: use variables instead of using register names directly
[23:08] <compn> gabor : btw, carl is the mentor for that vdpau project, so please contact him via email Carl Eugen Hoyos <ce at hoyos.ws>
[23:20] <cehoyos> Compn: Gabor is "auto-away"
[23:37] <cone-226> ffmpeg 03Vilius Grigaliknas 07master:ff6b08141a30: acvodec/lipopenjpeg: Fix pixel value shift for 12-bit pixel formats
[00:00] --- Wed Mar  4 2015