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

[burek]

[00:08] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:40cb682ca0b9: doc/faq: mention concat protocol documentation in the protocol concatenation entry
[00:08] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:2756c3091a9d: doc/faq: fill missing word in the concat protocol entry
[00:08] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:069d15645413: lavf/img2dec: fix option help fields
[00:08] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:1ec3324f00e7: lavf/img2enc: extend current options documentation
[00:49] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:c4738c319610: ffmpeg: fix typo in open_files() message
[01:27] <Compn> Cisco Exits the Consumer Market, Sells Linksys To Belkin
[01:28] <Compn> not that it makes much difference in quality :P
[01:38] <gnafu> I stopped caring about Linksys when they were bought by Cisco.  I've always hated Belkin, for whatever reason, so this is almost worse to me.
[01:39] <gnafu> "I was quit [when they were bought by Cisco].  I'm twice as quit now [that they were bought by Belkin]."
[01:43] <llogan> i still use an old WRT54G*.
[01:47] <Compn> those plastic blue network hubs/routers are terrible
[01:47] <Compn> metal ones arent bad :)
[03:06] <cone-871> ffmpeg.git 03Carl Eugen Hoyos 07master:a0d1440476ce: Fix compilation with --disable-everything on x86_32.
[03:17] <ulatekh> Anyone here?  I have a question & no one is responding on #ffmpeg.
[03:28] <Darkarnium> Compn: the WRT54GLs were good though :(
[03:29] <Darkarnium> As were the original WRT54GS, etc.
[03:29] <Darkarnium> Doesn't matter as much now as single board PCs are so cheap, but they were great for hardware hacks previously
[03:44] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:286930d302fd: gifdec: check that w,h is not zero
[03:44] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:e9d443cf0850: eacmv: Free frames on resolution changes
[05:43] <Mista_D> just a quick question, can ffmpeg route libavfilter(idet) output to csv/json format?
[05:50] <Mista_D> Or can ffprobe use detection filters as `idet`?
[06:24] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:ab6c9332bfa1: vqavideo: check chunk sizes before reading chunks
[07:00] <funman> michaelni: do you keep LIBAVUTIL_VERSION_MICRO >= 100 as for libavcodec?
[07:14] Action: funman assumed so
[07:27] <michaelni> funman, yes but iam sleeping ATM
[11:05] <funman> michaelni: alright, good night
[11:09] <durandal_1707> michaelni: how 286930d302fd34cf can be true?
[11:25] <durandal_1707> lol, luzero addding x264-params ....
[11:36] <jeje> hello ;-)
[11:40] <jeje> I have a question about avcodec_decodevideo2 function
[11:40] <jeje> in fact, I use FFMPEG to decompress video streaming from IP camera in H264
[11:41] <av500> sounds reasonable
[11:41] <jeje> the video source is in YUV420 and I use swscale to render directly in a DDRaw surface in RGB32
[11:42] <jeje> I have some problem with some video resolution 
[11:43] <jeje> when I can divide the width resolution with 32, it work well but when the video resolution can't be divide by 32, I have to add the modulo part
[11:43] <jeje> in fact, i do
[11:43] <jeje> av_image_fill_linesizes(m_lpFrame->linesize, PIX_FMT_YUV420P,dwWidth+(dwWidth%32)+32);
[11:44] <jeje> it work if I do this, but I can't explain me why...
[11:44] <durandal_1707> buffers must be padded it is in documentation
[11:48] <jeje> you tell me I have to pad the input buffer or the output buffer?
[11:49] <jeje> I'm sorry by I don't find this part in the documentation
[11:50] <durandal_1707> jeje: i told you already, now please ask further questions in correct channel #ffmpeg and not here
[11:51] <jeje> ok sorry
[12:56] <burek> I've found this link by accident http://www.evermeet.cx/public/ffmpeg/snapshots/
[12:56] <burek> it looks like the guy has set up static FFmpeg binaries for Mac OS X Intel 64bit
[12:57] <burek> if someone is using MacOS, we could check if it's ok and add it to the downloads page?
[12:57] <burek> oh.. it's already there.. just ignore me :S
[13:01] <durandal_1707> michaelni: looping over pointer in for is faster than using array[i]
[13:29] <burek> am i doing something wrong or this version of ffmpeg does not exist: N-48289-g9d8db19-tessus
[13:29] <burek> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9d8db19
[13:51] <cone-871> ffmpeg.git 03Janne Grunau 07master:8e148b874220: arm: h264qpel: use neon h264 qpel functions only if supported
[13:51] <cone-871> ffmpeg.git 03Janne Grunau 07master:6bdb841b46d1: h264: copy h264qpel dsp context to slice thread copies
[13:51] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:91ae9bc51e0f: Merge commit '6bdb841b46d170d58488deaed720729b79223b1d'
[13:56] <michaelni> durandal_1707, the amd optimization manual says the opposit IIRC
[13:56] <michaelni> also iam not sure to what code you refer to
[13:57] <durandal_1707> the one in gifdec
[13:57] <durandal_1707> reading pallete or any other for loop
[13:59] <cone-871> ffmpeg.git 03Paul B Mahol 07master:f1412c799732: lavc/gifdec: use memcpy()
[13:59] <cone-871> ffmpeg.git 03Paul B Mahol 07master:aaebdce3d907: lavc/gifdec: simplify "!= 0" checks
[13:59] <cone-871> ffmpeg.git 03Paul B Mahol 07master:285128eedf9e: lavc/gifdec: do not return nonzero *got_frame if frame is not passed
[13:59] <cone-871> ffmpeg.git 03Paul B Mahol 07master:51c7af9d3237: lavc/gifdec: move idx_line allocation out of gif_read_header1()
[13:59] <cone-871> ffmpeg.git 03Paul B Mahol 07master:7003d650b075: lavc/gifdec: remove obsolete check
[14:08] <cone-871> ffmpeg.git 03Paul B Mahol 07master:d07b0d992736: swscale: check flags instead of nb_components to find if pixel format have alpha
[14:22] <cone-871> ffmpeg.git 03Janne Grunau 07master:c5c2060cf597: x86: h264qpel: add cpu flag checks for init function
[14:22] <cone-871> ffmpeg.git 03Diego Biurrun 07master:2c10e2a2f624: build: Make the H.264 parser select h264qpel
[14:22] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:e9125dd55634: Merge commit '2c10e2a2f62477efaef5b641974594f7df4ca339'
[14:28] <cone-871> ffmpeg.git 03Luca Barbato 07master:4333df63551c: avstring: K&R formatting cosmetics
[14:28] <cone-871> ffmpeg.git 03Diego Biurrun 07master:33552a5f7b6e: arm: Add mathops.h to ARCH_HEADERS list
[14:28] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:b2d0c5bd13ab: Merge commit '33552a5f7b6ec7057516f487b1a902331f8c353e'
[14:45] <cone-871> ffmpeg.git 03Vittorio Giovara 07master:a84fb6e06f7f: h264: Allow discarding the cropping information from SPS
[14:45] <cone-871> ffmpeg.git 03Vladimir Pantelic 07master:b85a5e87af42: lavu: Add av_strnstr()
[14:45] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:25be63005f0b: Merge commit 'b85a5e87af4254b80913fe33591d96361f30832b'
[14:46] <durandal_1707> lol, now changelog will be full of libc cloned functions....
[14:47] <wm4> av_nih
[14:49] <ubitux> hellow :)
[14:50] <durandal_1707> wtf, what is wrong with people: http://linuxaudio.org/mailarchive/lau/2013/1/12/195808
[14:50] <ubitux> heh, luca adding API info into Changelog again?
[14:50] <durandal_1707> no av500 on behalf of someone i guess
[14:51] <av500> ...It seems madness to me that cdrecord would be considered obsolete.
[14:52] <av500> durandal_1707: ???
[14:52] <av500> durandal_1707: do you see strnstr() in libc?
[14:52] <av500> I dont
[14:53] <durandal_1707> yup, it is here
[14:53] <av500> BSD
[14:53] <av500> yes
[14:53] <durandal_1707> poor you :/
[14:53] <av500> not poor at all
[14:55] <av500> and as usual, ffmpeg is free not to merge stuff :)
[14:56] <wm4> not merging significant changes == suicide
[14:57] <av500> so far av_strnstr() is unused :)
[14:58] <durandal_1707> i only loled on changelog..
[14:59] <durandal_1707> wm4: what significant changes? move/rename/K&R formating/remove...
[15:06] <michaelni> ubitux, hellow :)
[15:08] <durandal_1707> and they are still struggling with "partial dirac hack"
[15:09] <wm4> what hack?
[15:09] <cone-871> ffmpeg.git 03Vladimir Pantelic 07master:0b55b16abc15: avfilter: allow setpts filter to use wallclock time for calculations
[15:09] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:fc2922836bc2: Merge remote-tracking branch 'qatar/master'
[15:10] <durandal_1707> that native dirac decoder output is not 100% same as reference implementation...
[15:32] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:495cb44172d0: setpts: deprecate RTCTIME, we have time(0) which is more generic
[17:02] Action: durandal_1707 cant understand how one can mistype ftp into tfp
[17:04] Action: michaelni acn
[17:22] <cone-871> ffmpeg.git 03Matthieu Bouron 07master:40b4468f6231: lavc/dnxhddata: fix bitrates for cid 1251 and 1252 in cid table
[17:30] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:13aca070ab83: gifdec: resync support
[17:48] <cone-63> ffmpeg.git 03Stefano Sabatini 07master:e4e36a4dd290: doc/filters: apply minor fixes
[17:55] <durandal_1707> lol why gif muxer does not use gif encoder but encodes on its own?
[17:56] <beastd> durandal_1707: dunno, maybe same reason gif demuxer didn't use gif decoder long times ago?
[17:57] <durandal_1707> beastd: yes but that code was removed... some thougt that muxer can live...
[17:58] <beastd> durandal_1707: muxer was not discussed at that time
[17:58] <beastd> IIRC the demuxer got into focus because Reimar (or maybe someone else) detected vulns in the demuxer
[17:59] <durandal_1707> lol muxer even have some kind of lut table
[17:59] <beastd> durandal_1707: you plan to work on the gif muxer? i guess cleanup would be appreciated too
[18:01] <durandal_1707> well, it is much more complicated ...
[18:14] <durandal_1707> why is only way to use showwaves/showspectrum via amovie?
[18:19] <durandal_1707> saste: i was wondering how to make showspectrum to render all channels and in more vivid colors
[18:19] <saste> durandal_1707, with ffplay?
[18:20] <saste> at the moment yes
[18:20] <saste> unless you want to port filter_complex from ffmpeg
[18:20] <durandal_1707> ffplay does not support even -af
[18:20] <saste> and i have a patch for adding -af to ffplay (but which doesn't help in this case)
[18:21] <durandal_1707> and why it is not on ml?
[18:22] <saste> durandal_1707, it is
[18:22] <saste> but in an old thread
[18:22] <saste> i still have to address some issues
[18:22] <saste> no one cares to comment about my image2 RFC?
[18:24] <beastd> saste: is it on ML?
[18:24] <saste> beastd, [RFC] image2 and filename patterns
[18:24] <beastd> if yes i will read it later 
[18:25] <beastd> is it related to the recent tickets on trac?
[18:25] Action: beastd works on sth else at the moment
[18:25] <beastd> but will read it later and comment tomorrow if that is not too late
[18:27] <saste> beastd, which tickets?
[18:28] <beastd> saste: not sure and for some reason i can't check. but i had the impression there were some tickets related to image2 (input) patterns
[18:29] <saste> no but there was a related discussion on ffmpeg-user
[18:29] <beastd> ok, will check
[19:08] <michaelni> did someone had some / worked on  gbrp* output for sws ?
[19:08] <michaelni> iam asking because if not ill look into it
[19:09] <wm4> I think Daemon404 had a half-working patch?
[19:10] <Daemon404> i have teh rgb path
[19:10] <Daemon404> but it was not applied since swscale cannot handle a rgb only path
[19:10] <Daemon404> it NEEDS a yuv path too
[19:10] <Daemon404> otherwise it will crash, rather than chain conversions
[19:11] <Daemon404> https://patches.libav.org/patch/27645/
[19:11] <Daemon404> make sure to read the replies
[19:12] <michaelni> can i see the patch ?
[19:12] <Daemon404> (i got teh title backwards!)
[19:12] <Daemon404> i just linked
[19:15] <bcoudurier> why gbrp instead of rgbp ?
[19:16] <wm4> because why miss an opportunity to confuse everyone?
[19:21] <Daemon404> bcoudurier, i just worked with whatever colorspace was already being used by things
[19:21] <Daemon404> and existed
[19:21] <Daemon404> ask whoever implemented it =p
[19:27] <saste> what should I do with CREDITS?
[19:27] <saste> michaelni, ok to mention the missing names in the log message?
[19:29] <wm4> saste: btw. I attempted to write a patch for the cookie issue mentioned yesterday; fixing the error handling was simple enough, but I'm not really sure what the semantics are for domain matching + port names
[19:30] <saste> wm4: what about CC-ing the author of the code (Micah Galizia)?
[19:30] <saste> i'm not an HTTP expert, but if you post the patch i'll try to review it
[19:40] <cone-63> ffmpeg.git 03Stefano Sabatini 07master:e80be5a0aa9f: lavfi/showwaves: fail in case of push_frame() error
[20:14] <michaelni> saste, IMO removing names that are then mentioned nowhere expcet a log message of one "random" commit doenst feel correct
[23:37] <michaelni> Daemon404, GBRP patches on ffmpeg-dev, your review is welcome if you want to review them
[23:46] <wm4> michaelni: can anything be done about the remaining missing conversions?
[23:48] <michaelni> wm4, which are missing ?
[23:49] <michaelni> ill add gbrp16 output support too probably ...
[23:50] <wm4> michaelni: some 64 bit RGB formats according to format_entries[], and some more weird formats
[23:51] <cone-154> ffmpeg.git 03Michael Niedermayer 07master:c6ef7641fc12: ffv1enc: fix gbrp>8bit
[23:53] <michaelni> i dont see a problem with adding the 64 bit formats
[23:54] <michaelni> what uses them ?
[23:54] <wm4> no idea
[23:55] <wm4> oh right, PNG
[23:57] <michaelni> ok, that should be useable for testing
[00:00] --- Sat Jan 26 2013