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

[burek]

[00:48] <cone-318> ffmpeg.git 03Uwe L. Korn 07master:7ce3bd961471: rtmpproto: Support alternative slist parameter in rtmp URLs
[00:48] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:d68ed9f257bd: Merge commit '7ce3bd9614717e545af8fb8455032c807e389b78'
[01:16] <Daemon404> ffmpeg now has exatly 1000 stars on github.
[01:16] <Daemon404> yay?
[01:17] <wm4> lol
[01:17] <J_Darnley> Yay 1000 internet points!
[01:17] <J_Darnley> What do we win?
[01:18] <BBB> 2 youtube dollars
[01:19] <BBB> (context: https://www.youtube.com/watch?v=idZOVqdcqno)
[01:20] <J_Darnley> South Park?
[01:25] <iive> we got internet money!!!
[01:40] <cone-318> ffmpeg.git 03James Almer 07master:4cdea9297679: swresample/resample: add missing xmm clobbers
[02:21] <Compn> what movie do you want to watch on youtube ?
[04:09] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:84655bdaed9c: avcodec/hevc: remove unused variable
[04:09] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:326463893beb: avcodec/wavpack: initialize pointers to silence warning about them possibly being uninitialized
[04:09] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:04b15a6055fc: avformat/h263dec: shift data in state to make more bits available to probe
[04:09] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:3ad21c50af04: avformat/h263dec/h263_probe: Check PSC bit 9 and 13 in
[04:09] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:cd20b93e2f51: avformat/h263dec/h263_probe: Check TR
[06:15] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:8dd435f0cf2f: cmdutils: include config.h, fix "is not defined" warning due to CONFIG_OPENCL
[06:15] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:134206ca7a3d: avformat/utils: fix const warnings
[07:42] <anshul> hi in nb_streams what does nb mean
[07:42] <ubitux> number of
[07:43] <anshul> thanks
[07:48] <anshul> there is a problem in ffprobe, nb_streams_packets are allocated by looking only part of the file, due to which size of nb_streams_packets is less if numbre of stream increase later in video
[07:50] <anshul> so is there any ffprobe context which save nb_stream at the time of allocation of nb_streams_packets, or should i store one more variable globally beside nb_streams_packets
[07:55] <anshul> packet.stream_index start from 0 or 1 
[08:02] <anshul> its start from 0
[09:10] <ubitux> anshul: yes there is a ticket opened about that issue i believe
[09:19] <anshul> yes #3603 , i am on it.
[09:28] <anshul> is it safe to give pointer from av_calloc to av_realloc
[09:29] <anshul> or should i av_calloc memory and assign previous memory value  to newly assigned memory
[09:34] <ubitux> that's called av_realloc
[09:34] <ubitux> make sure first call is a realloc too though
[09:39] <plepere> hi all
[09:39] <plepere> got the feedback on the hevc patch
[09:40] <plepere> I'm doing some changes on the hevcdsp_init.c to give it more modularity
[09:53] <ubitux> grumbl archlinux rebuilding ffmpeg with 4.9
[09:53] <ubitux> (https://bugs.archlinux.org/task/40256)
[09:53] <JEEB> yeah, there was a guy on #ffmpeg yesterday
[09:55] <JEEB> seems like this aphirst dude didn't care to report it further than the IRC channel :P
[10:03] <anshul> ubitux, actually in ffmpeg memory is allocated using mmap(depend on configuration), while realloc has to be given pointer which was given by malloc, realloc or calloc, so I was wondering whether it is safe or not.
[10:03] <ubitux> it's not, it's in the doxy
[10:04] <ubitux> see @warning
[10:07] <anshul> there is place where av_calloc is used to allocate according to number of stream, but after some time streams are increased, i need to realloc it so if i use av_realloc that would be safe or not.
[10:08] <ubitux> replace the original av_calloc with a av_realloc
[10:09] <ubitux> (use a NULL)
[10:11] <anshul> ok thanks
[10:27] <anshul> clement, as u asked "mark the fix in the description, and describe the fix in the title" I marked it fixed, but i didnt got the second part.
[10:28] <ubitux> i meant to use something like "ffprobe: fix crash because of new streams occuring" and 2 lines below "Fix ticket #3603"
[10:29] <ubitux> anshul: also while at it, please fix your spacing
[10:29] <ubitux> another thing i don't like is that i don't see any overflow check
[10:30] <ubitux> and i'm not sure about of the new static int nb_stremas: fmt_ctx->nb_streams should be enough
[10:30] <ubitux> anshul: do you want me to state all of this on the ml?
[10:31] <anshul> no i am doing it 
[10:31] <ubitux> beastd: i'll reply to your mail later, sorry about the anger unleash btw
[10:32] <beastd> Hey ubitux!
[10:33] <beastd> No problem and no hurry. I will be travelling in about 1h and probably get to look at mails again somewhen tonight.
[10:34] <beastd> now to sth completely different...
[10:38] <beastd> i have been experimenting with Trac and found a way to make the view tickets from the top menu bar just use the query module and output a formatted table with the result. i think it is more comfortable than how things are working now where you get a list of reports first and than need find the report you want to execute and do another click.
[10:40] <beastd> ubitux: i think you have mentioned that you find it cumbersome too. somewhen later this month i will create a ticket and ask if the behaviour should be changed.
[10:41] <anshul> ubitux, i have used int nb_streams for saving number of stream at the time of allocating nb_stremas_packets, since size of nb_streams_packet is always equal to this new static nb_streams
[10:42] <anshul> this static nb_streams(size of array)  is checked for checking overflowing
[10:42] <ubitux> beastd: yeah definitely
[10:45] <ubitux> anshul: sounds clumsy since there is nb_streams_{frames,packets,...}
[10:45] <ubitux> anshul: btw, you could drop the initial av_realloc altogether
[10:45] <ubitux> oh wait my bad the "nb_" are tabs
[10:46] <ubitux> well, what about calling av_realloc unconditionnally? :)
[10:47] <ubitux> like, drop all the nb_streams_* = av_calloc(), and before nb_streams_packets[...] you just realloc with fmt_ctx->nb_streams
[10:47] <ubitux> mmh that won't do for the zero padding, which you're not handling anyway
[10:48] <ubitux> oh well, i'll wait for your next iteration
[10:49] <ubitux> anshul: space before * and (, look at the surrounding style please
[10:50] <ubitux> where do you memset to zero the new added stream(s) counters?
[10:50] <anshul> where should nb_streams_* free all the reallocated thing
[10:50] <anshul> ok i will look at * and (
[10:51] <ubitux> the memset is more important
[10:51] <ubitux> static nb_streams should be fine, i just missed that originally
[10:52] <anshul> ok i will add memset and done * and ( locally
[10:52] <ubitux> but since it's zero i still think you should just have the realloc code once (and simply drop the av_calloc)
[10:53] <anshul> i agree with you
[10:54] <anshul> but allocating in read_interval_packets and free in probe_file looks odd to me
[10:55] <anshul> is it a better idea to remove those static pointer and move them to avformat
[10:57] <anshul> ubitux, is cehoyos your name in trac or is he carl Euegon
[10:58] <ubitux> "ce" from "cehoyos" stands for carl eugen
[11:01] <anshul> if i remove realloc completely from probe file, then nb_streams_frames and selected_streams  may be used before
[11:04] <ubitux> ok
[11:52] Action: beastd is leaving
[11:52] <j-b> to?
[11:53] <beastd> Heading to Berlin now :)
[11:53] <beastd> j-b: Do you know who will be there from VideoLAN?
[11:54] <j-b> beastd: EVERY-ONE
[11:54] <j-b> beastd: like EVERY-fucking-ONE
[11:56] <beastd> j-b: oha. So you will be on LinuxTag too?
[11:57] <beastd> anyways, i am out. bye...
[13:34] <anshul> What does analyse by developer mean in ffmpeg trac, after analysing ticket i marked the ticket analyse, does it mean something else.
[13:38] <Daemon404> ubitux, remind me why av_calloc is incompatible
[13:38] Action: Daemon404 always forgets the malloc/realloc/calloc business
[13:40] <kierank> alignment probably
[13:40] <anshul> av_calloc use mmap function, av_realloc use realloc function, in linux realloc manual it is specified that there is undefined behaviour if pointer passed to realloc is not given by malloc calloc or realloc
[13:42] <Daemon404> i guess it uses mmap for 'performance reasoons
[13:42] Action: Daemon404 is not sure why calloc would use mmap
[13:42] Action: Daemon404 checks source
[13:42] <kierank> yeah i doubt it uses mmap
[13:43] <kierank> realloc isn't guaranteed to get you an aligned pouinter
[13:43] <Daemon404> it doesnt
[13:43] <Daemon404> i mena
[13:44] <Daemon404> av_calloc calls av_mallocz which calls av_malloc
[13:44] <Daemon404> which calls posix_memalign on most systems
[13:44] <Daemon404> which != malloc
[13:46] <Daemon404> i dont actually see that we've documented it anywhere that you cant use av_malloc and av_realloc
[13:46] <Daemon404> and the names suggest you can.
[13:47] <anshul> its documented in doxy
[13:48] <anshul> actually av_calloc use av_malloc
[13:48] <Daemon404> indeed i already said that
[13:49] <Daemon404> where in doxy is it
[13:49] <anshul> sry , didnt came till last message
[13:49] <Daemon404> ok i see it in doxy
[13:49] <Daemon404> doesnt mention calloc though
[13:50] <anshul> I dont seen doxy but in source code above av_realloc defination
[13:51] <anshul> calloc is not having any problem it av_realloc which should we not called after av_malloc and av_calloc
[13:51] <anshul> What does analyse by developer mean in ffmpeg trac
[13:52] <Daemon404> it means a developer has looked at it
[13:53] <anshul> so what define developer
[13:53] <anshul> since every time i mark a ticket as analysed then cehayos unset it.
[13:56] <Daemon404> carl is an asshole
[13:56] <Daemon404> thats the only reason
[13:59] <anshul> hmmmm
[13:59] <Daemon404> anshul, i wouldnt worry
[14:00] <Daemon404> just mark it as fixed one the fix is pushed
[14:00] <Daemon404> he cant really argue with that
[14:01] <anshul> yup, i dont worry about that, urs idea is good
[14:07] <iive> anshul: do you write the result of the analysis as a comment in the ticket?
[14:08] <J_Darnley> anshul: perhaps the "analysed by developer" flag keeps getting unset because carl doesn't recognise you on trac and thinks some random newbie keeps setting a flag he (the newbie) doesn't know the meaning of
[14:27] <anshul> iive, yes i wrote my analysis
[15:04] <ubitux> can't we do something better than link->time_base = av_inv_q(s->framerate); in the fps filter?
[15:05] <ubitux> i have serious problems here because of this
[15:05] <Daemon404> how could somerthing be "better"
[15:06] <ubitux> well, the typical problem i'm having here is that i'm trying to extract regular thumbnails doing sth like ffmpeg -i in.mp4 -vf fps=0.45,scale=120:80,tile=10x3 -y -frames:v 1 out.jpg
[15:07] <ubitux> fps is calculated using the duration and the number of frame we want (here 30)
[15:07] <ubitux> oh mmh wait
[15:08] <Daemon404> i dont think you should be gettign fps involved to extract thumbs
[15:15] <ubitux> i was doing something wrong, it actually works fine
[15:15] <Daemon404> o ok
[15:15] <ubitux> Daemon404: well, do you have another solution to get regular frames?
[15:16] <ubitux> i could use select, but it's the same as fps typically
[15:16] <Daemon404> >vfr
[15:16] <ubitux> ?
[15:16] <Daemon404> time based is what you want
[15:16] <Daemon404> oh wait, yorue changing teh fps
[15:16] <ubitux> fps is time based, select can be as well
[15:16] <nevcairiel> Daemon404: in the real world, people don't care about vfr :P
[15:16] <Daemon404> nevcairiel, i dunno
[15:16] <Daemon404> i get paid to care about vfr
[15:17] <nevcairiel> many companies dont live in the real world
[15:17] <Daemon404> i cant really ignore vfr
[15:17] <Daemon404> no more than youtube can
[15:17] <nevcairiel> because 1 in 10000 uses it? :d
[15:17] <Daemon404> significantly mroe
[15:17] <Daemon404> iphones capture vfr
[15:17] <JEEB> well, youtube just converts everything to specific video rates
[15:17] <Daemon404> and many MANY professional editors output vfr
[15:18] <Daemon404> either using edit lists or just pts/dts
[15:19] <ubitux> iphone captures vfr but randomly
[15:19] <Daemon404> yes
[15:19] <Daemon404> so do some android phones
[15:19] <ubitux> it's cfr unless luma change :')
[15:19] <ubitux> and then suddenly surprise
[15:19] <Daemon404> ubitux, and it looks horrible
[15:19] <Daemon404> :D
[15:20] <nevcairiel> phones typically only capture vfr when they notice their crappy hardware can't keep up
[15:20] <nevcairiel> at least thats one random factor in androids capturing, not sure about iphones
[15:21] Action: Daemon404 goes to poek swscale, weeps inside
[15:21] <Daemon404> adding new pix fmt is not very fun
[15:42] Action: Daemon404 wonders why new hevc stuff is beign submitted while the old stuff is still broken
[15:45] <plepere> Daemon404, it's because I've been working on ASM for some time now, and the performance boost is really necessary for everyone.
[15:45] <Daemon404> it would be even better if it didnt crash
[15:45] <Daemon404> which is kind of also important
[15:45] <plepere> obviously.
[15:45] <plepere> you're referring to the win32 crashing ?
[15:45] <Daemon404> yes
[15:46] <plepere> ok, I'm checking it out. hopefully it's only an ASM problem.
[15:46] <Daemon404> well, win64.
[15:48] <Daemon404> [14:45] < plepere> Daemon404, it's because I've been working on ASM for some time now, and the performance boost is really necessary for everyone. <-- fyi though, 32-bit windows is the largest consumer of ffmpeg, technically :P
[15:48] <Daemon404> and no such asm exists
[15:49] <smarter> plepere: I have a cleaned up version of the deblocking asm at https://github.com/smarter/libav/tree/hevc_dbl_asm if you're planning on sending it to the ML (otherwise I'll do it once I have the time)
[15:50] <ubitux> mmh why ffmpeg -i in.mp4 -vf fps=0.5 -frames:v 1 a.png and without -vf fps doesn't give the same thing?
[15:50] <plepere> smarter : I'll try to get win64 compilation working first, but I'm keeping your adress in my favorites. thanks
[15:50] <ubitux> mmmh i mean with a seek
[15:51] <ubitux> jeez my brain is off or what
[15:53] <smarter> Daemon404: chrome should distribute a binary that contains both a 32 bits and a 64 bits version of itself, problem solved :p
[15:53] <Daemon404> ;p
[15:53] <Daemon404> smarter, the other big distributer is steam
[15:53] <Daemon404> because it uses chromium
[15:54] <smarter> though neither of them care about hevc
[15:54] <Daemon404> yet
[15:55] <Daemon404> nobody *really* cares about hevc yet
[15:55] <Daemon404> since nothing can beat x264 consistently
[15:55] <smarter> I don't see hevc in <video> ever happening
[15:55] <plepere> Daemon404, steam could use hevc in their streaming at home thing.
[15:55] <JEEB> plepere, after the implementations get somewhere
[15:56] <Daemon404> smarter, i do
[15:56] <Daemon404> if not solely for MS
[15:57] <kierank> Daemon404: they do care
[15:57] <Daemon404> kierank, not for any legiitmate reasons
[15:57] <Daemon404> marketing isnt legitimate
[15:57] <cone-904> ffmpeg.git 03Matt Oliver 07master:1898c2f49da3: inline asm: fix arrays as named constraints.
[15:58] <kierank> smarter: why not
[15:58] <Daemon404> because smarter works on vp9
[15:58] <Daemon404> /troll
[15:58] <kierank> if iphone supports it
[15:58] <kierank> it'll happen
[16:06] <kierank> i think hevc could go the way of mpeg-4 asp
[16:06] <kierank> patent hell
[16:07] <Daemon404> fun
[16:07] <Daemon404> not that it ever stopped pirates form using it
[16:28] <nevcairiel> people didnt want mpeg2 to live for ever, so what was there instead!
[16:38] <nevcairiel> I really wonder why someone would bother with ICL, it seems to cause new problems every day
[16:38] <nevcairiel> and the code isn't really faster, at least not fast enough to warrant it
[17:13] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:efbf107f5b28: avfilter/aeval: silence "may be used uninitialized" warning
[17:13] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:eeb48353abaa: avcodec/ac3enc: silence 2 warnings about "possibly uninitialized" variables
[17:16] <michaelni> ubitux, did you post the coverage.ffmpeg.org link to the ML ? if not i think you should, it would make sense if people see where test coverage is lacking and its imho important that we improve test coverage
[17:18] <ubitux> michaelni: i believe i did on various occasions
[17:18] <ubitux> michaelni: but i think it should be part of the website
[17:19] <ubitux> that's the reason i wanted a new website but... well it's stalled
[17:19] <ubitux> we juste need a stupid left menu with categories to move all the shit in trees in it
[17:19] <ubitux> so we can add random entries
[17:19] <ubitux> i think i'll end up taking 2-3 hours to do that
[17:20] <ubitux> but fuck, i hate web :(
[17:25] <ubitux> michaelni: db0 was stalled because of that last thread, i told her she should just continue to do it anyway, so here we go
[17:26] <michaelni> i agree it should be part of the website, also, if you see something that i could do to unstall this or otherwise ...
[17:27] <michaelni> also we maybe could remove some stuff from the top naviatio line or make it 2level with a second line based on what is selected in the first
[17:28] <michaelni> or drop down menu style
[17:28] <michaelni> but either it should have some fallback for people who disabled javascript if possible
[17:28] <michaelni> if it uses javascript that is
[17:30] <ubitux> db0 was going to do a drop down menu; i would personally prefer something like http://www.musicpd.org/ simply
[17:31] <ubitux> so you don't have to care about various compat issue with js & shit
[17:33] <michaelni> agree, that looks nice too
[18:20] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:a779602584b4: avcodec/eamad: silence uninitialized variable warnings
[18:20] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:a6e9448dc697: avcodec/cinepakenc: Zero AVPictures, silence "may be used uninitialized" warnings
[18:20] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:54ae58802e98: avcodec/cinepakenc: drop coded_frame init
[00:00] --- Thu May  8 2014