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

[burek]

[01:53] <cone-975> ffmpeg.git 03Michael Niedermayer 078824a9ed2291: mpeg12: clean current picture ptr.
[01:53] <cone-975> ffmpeg.git 03Michael Niedermayer 07b5f4836f8cb3: vc1: check image height, fix division by 0
[01:53] <cone-975> ffmpeg.git 03Michael Niedermayer 078e749733c135: vc1dec: factorize srcU/V offseting out
[01:53] <cone-975> ffmpeg.git 03Michael Niedermayer 073a04c18d899d: vc1dec: prevent null ptr dereferences.
[04:26] <hyun> hi 
[04:26] <hyun> is there a source for rtp jpeg encoder in ffmpeg?
[04:39] <Compn> why? you want to copy paste some homework ? :P
[04:40] <Compn> ffmpeg/libavformat/rtpenc_jpeg.c
[04:41] <hyun> I don't see that file I am using 0.10
[04:43] <hyun> kind of homework, I worked for streaming industry more than 10 years
[04:45] <hyun> Oh I see that file in different branch
[04:50] <hyun> I was looking for example of restart marker handling but this version hasn't implemented yet.
[05:16] <Compn> hyun : ah, welcome :)
[05:33] <sandsmark> «worked for streaming industry more than 10 years»  fancy name for a camgirl? :]
[05:46] <hyun> sandsmark : live show?
[05:46] <hyun> sorry mate I am a man.
[05:46] <hyun> hyun is middle name
[05:47] <sandsmark> yeah, I was just kidding :P
[05:47] <sandsmark> (just found the statement a bit ambigous, you can do a lot for the streaming industry)
[05:48] <hyun> agree, english is my second
[09:02] <ubitux> do not try at home: zsh ./configure
[11:08] <cone-868> ffmpeg.git 03Diego Biurrun 07f0d124f005ff: x86inc: Set program_name outside of x86inc.asm
[11:08] <cone-868> ffmpeg.git 03Anton Khirnov 07e5e1a06e443f: configure: add lavu dependency to lavr/lavfi .pc files
[11:08] <cone-868> ffmpeg.git 03Alberto Delmás 07b077eb07805d: mss2: fix handling of unmasked implicit WMV9 rectangles
[11:08] <cone-868> ffmpeg.git 03Kostya Shishkov 076d93308c0ca3: mss2: reindent after last commit
[11:08] <cone-868> ffmpeg.git 03Alberto Delmás 07802713c4e7b4: mss2: prevent potential uninitialized reads
[11:08] <cone-868> ffmpeg.git 03Michael Niedermayer 07da501ea857b1: Merge commit '802713c4e7b41bc2deed754d78649945c3442063'
[11:50] <cone-868> ffmpeg.git 03Justin Ruggles 075980f5dd1882: lavu: rename audioconvert.* to channel_layout.* and deprecate audioconvert.h
[11:50] <cone-868> ffmpeg.git 03Justin Ruggles 07a903f8f087b0: Include libavutil/channel_layout.h instead of libavutil/audioconvert.h
[11:50] <cone-868> ffmpeg.git 03Diego Biurrun 0797bf7c03b133: doc: git-howto: Leave reviewers time to react before pushing patches
[11:50] <cone-868> ffmpeg.git 03Michael Niedermayer 0703b078721c8e: Merge commit '97bf7c03b1338a867da52c159a2afecbdedcfa88'
[12:18] <cone-868> ffmpeg.git 03Diego Biurrun 07b8e8a07c6c4d: x86: Require an assembler able to cope with AVX instructions
[12:18] <cone-868> ffmpeg.git 03Diego Biurrun 072b479bcab0a8: build: Drop AVX assembly ifdefs
[12:18] <cone-868> ffmpeg.git 03Michael Niedermayer 078c0a14d221af: Merge commit '2b479bcab0a8365a7c094c5fa44b8cb6da9810d0'
[12:24] <cone-868> ffmpeg.git 03Justin Ruggles 07faf340f60c18: binkaudio: set channel layout
[12:24] <cone-868> ffmpeg.git 03Michael Niedermayer 074d60e5051e66: Merge remote-tracking branch 'qatar/master'
[12:43] <burek> ubitux thanks :)))
[12:43] <burek> (about huffyuv)
[12:44] <durandal_1707> what about?
[12:54] <durandal_1707> burek: user claims source is 24bit but that just cant be true
[12:55] <burek> durandal_1707 how come?
[12:55] <durandal_1707> output of ffmpeg is yuv422 in both case
[12:58] <durandal_1707> wtf why yuy2 in huffyuv is not supported at all?
[12:59] <burek> what are you talking about?
[12:59] <burek> why is it impossible to have 24bit huffyuv?
[13:00] <durandal_1707> 24bit huffyuv is 24 bit rgb888
[13:00] <durandal_1707> looking from the code
[13:00] <cone-868> ffmpeg.git 03Paul B Mahol 070baec57d09eb: anm: return meaningful error codes
[13:00] <cone-868> ffmpeg.git 03Paul B Mahol 07e8a9b1a1a0ed: adpcm: ADPCM IMA SMJPEG stereo decoding
[13:00] <cone-868> ffmpeg.git 03Paul B Mahol 070cbb31a26485: adpcm: reindent after previous commit
[13:01] <burek> <@durandal_1707> burek: user claims source is 24bit but that just cant be true
[13:01] <burek> im asking about this
[13:01] <burek> how is it not possible?
[13:02] <durandal_1707> because ffmpeg ouput says yuv422p for source
[13:02] <burek> oh i see
[13:02] <burek> should i ask for a sample?
[13:02] <durandal_1707> and even if source was 24bit rgb it should stay rgb pix fmt and not change to yuv
[13:03] <durandal_1707> burek: tell user is it really 24 bit rgb
[13:03] <burek> i see, that makes sense :)
[13:04] <burek> thanks :)
[13:04] <durandal_1707> another strange thing is increased size by 50%
[13:08] <burek> does huffyuv support RLE compression of some kind
[13:13] <durandal_1707> no it is using huffman coding as name says, but it is lossless and for lossless 50% diff of size is very big
[13:18] <burek> should I just redirect him to the bug tracker?
[13:19] <durandal_1707> burek: if he found bug (otherwise his bug report may be just invalid)
[13:19] <burek> better to have even invalid report, than nothing :)
[13:22] <divVerent> 13:00:13 @durandal_1707 | 24bit huffyuv is 24 bit rgb888
[13:22] <divVerent> 13:00:22 @durandal_1707 | looking from the code
[13:22] <divVerent> not really
[13:22] <divVerent> or rather
[13:22] <divVerent> huffyuv is never 24bit ;)
[13:22] <divVerent> ffvhuff is the ffmpeg extension huffyuv derived codec
[13:22] <divVerent> which however lacks predictors in the non-yuv cases
[13:22] <divVerent> (other than the "difference to previous pixel" one)+
[13:23] <burek> btw, would it be better to edit the bugreports.html in such a way that it shows a little bit less information, like for example bullets of important steps, which can expand if the user clicks on it, to get some more info or something..
[13:23] <burek> this way, page looks a little too big and people might probably not even read it
[13:24] <burek> or to make a short summary at the top or something
[13:25] <durandal_1707> divVerent: how so? i see rgb24 for huffyuv encoder
[13:25] <divVerent> durandal_1707: yes
[13:25] <michaelni> burek, sounds interresting but hard to say without seeing actual html
[13:26] <divVerent> durandal_1707: oh wait, sorry
[13:26] <divVerent> yes
[13:26] <divVerent> only yuv420p is a ffmpeg extension
[13:26] <divVerent> but the non-yuv cases are crap
[13:26] <divVerent> they don't even pick a predictor, they always use sub_left_prediction
[13:27] <divVerent> so it basically is a huffman-encoded difference to the previous pixel
[13:31] <durandal_1707> michaelni: what to limit number of samples (frame size) for smackaud?
[14:12] <TimNich>  
[14:33] <ubitux> http://sprunge.us/gggY  i get a user with this problem
[14:33] <ubitux> which i'm unable to reproduce
[14:33] <ubitux> any idea?
[14:35] <ubitux> http://sprunge.us/AUGT
[14:35] <ubitux> dst buffer is NULL, i have no idea why
[14:46] <durandal_1707> different alsa/pulse version?
[14:47] <ubitux> possibly, but it shouldn't crash here
[14:47] <ubitux> dst buffer is NULL, and there is no check
[14:47] <ubitux> something looks wrong to me
[15:12] <cone-868> ffmpeg.git 03Michael Niedermayer 07be818df547c3: wavpack: fix out of array access
[15:12] <cone-868> ffmpeg.git 03Michael Niedermayer 07c433823750bf: 4xmdec: test version for cfrms, fix out of array accesses
[16:32] <durandal_1707> michaelni: that wavpack change looks wrong
[16:41] <michaelni> durandal_1707, yes but thats the amount that is written in there, either the buffer is that size or the code is made to write less which didnt look prettier
[16:42] <durandal_1707> michaelni: also the warning that checks block_samples in demuxer look wrong too, shouldn't it use RL and not RN?
[16:52] <cone-868> ffmpeg.git 03Paul B Mahol 0787c113f4b3b8: wv: use right function to read block_samples
[16:59] <burek> how can I tell git to just purge all the local changes and just sync with whatever is the current git pull version
[17:03] <burek> never mind, i just did rm -rf and git clone again :)
[17:04] <durandal_1707> that is extremly stupid
[17:04] <burek> yeah but it works
[17:09] <burek> michaelni, I've sent the proposal for reorganization of bug reports page on ffmpeg-devel ml
[17:09] <burek> so you can see what I mean
[17:09] <cbsrobot> burek: git reset --hard HEAD
[17:10] <burek> oh.. thanks..
[17:10] <burek> I was missing the "HEAD" part
[17:10] <burek> :D
[17:10] <cbsrobot> but that will remove all your changes
[17:10] <burek> what an ironic sentence
[17:10] <burek> :D
[17:10] <cbsrobot> see http://marklodato.github.com/visual-git-guide/index-en.html
[17:11] <cbsrobot> maybe you want to keep the changes
[17:11] <burek> no, i just wanted a fresh copy to make a patch against it
[17:11] <cbsrobot> and just get back to a good starting point
[17:12] <cbsrobot> I suggest you keep you master branch clean
[17:12] <cbsrobot> so you can always git pull the latest head
[17:12] <cbsrobot> and work on branches for your patches
[17:13] <burek> I agree
[17:38] <burek> er..
[17:38] <burek> ..S... text                 raw UTF-8 text
[17:38] <burek> (the output of ffmpeg -codecs)
[17:38] <burek> there is no 'E' nor 'D' there
[17:38] <burek> what does that mean
[17:39] <burek> it doesn't support neither encoding nor decoding of raw UTF-8 text? :)
[17:39] <durandal_1707> that ffmpeg is not text editor
[17:39] <burek> for example:
[17:39] <burek> DES... xsub                 XSUB
[17:39] <burek> it has both 'D' and 'E'
[17:41] <burek> also dvb_teletext and eia_608 don't have neither D or E
[17:41] <ubitux> < burek> ..S... text                 raw UTF-8 text // wait, there should be a decoder now.
[17:41] <burek> is it mistake in help or what
[17:41] <ubitux> i added a text decoder a while ago.
[17:45] <durandal_1707> so how it works?
[17:45] <ubitux> it helps saving the subtitles you decode from format with this codec
[17:45] <ubitux> such as ogg, and maybe flv
[17:47] <burek> so, it's not an encoder
[17:47] <ubitux> indeed, 'D' stands for "decoder"
[17:47] <ubitux>  D.S... text                 raw UTF-8 text
[17:47] <ubitux> subtitles decoder.
[17:49] <burek> hm, I have no 'D'
[17:49] <burek> let me check again
[17:51] <burek> ok, my version was from october, now it does have 'D' :)
[17:51] <burek> but dvb_teletext and eia_608 still don't have neither 'D' nor 'E'
[17:51] <burek> is that supposed to be that way
[17:52] <burek> try ffmpeg -codecs | grep ^.\\.\\.
[17:52] <burek> there are other codecs who also don't have 'D' or 'E' set
[17:53] <ubitux> that means we don't have a decoder nor encoder
[17:53] <burek> but.. but..
[17:53] <ubitux> dvb or eib608 are just recognized as data, but we can't decode (make sense of them) nor encode them
[17:53] <ubitux> we can just copy them between containers, eventually
[17:54] <burek> so, we can detect what it is, but can't do anything with it, except for copy
[17:54] <burek> ok, makes sense
[17:54] <burek> i thought it was a missing info in help or something
[18:04] <burek> btw, I just remembered I wanted to ask something
[18:05] <burek> earlier before
[18:05] <burek> data streams contain some data, that is usually not audio, video, subs or something usual
[18:05] <burek> is it possible to load a file and just mux it as data stream with audio/video ? :)
[18:05] <burek> using ffmpeg of course
[18:06] <burek> for example an image of the cd cover or something
[18:12] <cone-868> ffmpeg.git 03Michael Niedermayer 079eef41b84893: lagarith: always allocate for 4 planes. Fixes out of array accesses
[18:12] <cone-868> ffmpeg.git 03Michael Niedermayer 07d1493d2ce5f5: theora: check that pix fmt is valid, fix null ptr deref
[18:27] <Prottey> Hi. Which tree is more upstream - libav on github or source.ffmpeg.org? or is there another "minefield" tree which gets the shiniest commits?
[18:28] <JEEBsv> source.ffmpeg.org for ffmpeg
[18:29] <JEEBsv> libav is libav, a fork
[18:29] <Prottey> thanks
[18:30] <Prottey> btw is there already a way to add another codec/muxer the "plugin" way - i.e. dynamically linking w/o rebuilding?
[18:30] <JEEBsv> not as far as I know...
[18:31] <Prottey> so what are the goals of that libav fork, if they stated?
[18:31] <JEEBsv> people had problems working together, forking happened. ffmpeg merges most if not all of the changes done there
[18:33] <Prottey> so basically, each branch receives its independent task list, then the results are tested in terms of compatibility, etc. and merged, am I right?
[18:34] <JEEBsv> both sides work mostly independently, more or less reviewed on their own side and then the other side looks at stuff and possibly merges
[19:04] <burek> btw, would it be a lot of work to implement the external encoders support in a plugin-style
[19:04] <burek> like gstreamer does it
[19:04] <ubitux> yes, and also a pain
[19:07] <burek> too bad :/
[19:07] <burek> it would really be cool if you miss an mp3 encoder, to just compile that and you're good to go
[19:07] <burek> especially for embeded devices, where compile time is too big to even consider recompiling of entire project
[19:08] <JEEBsv> I do agree that it could be an interesting feature, but usually stuff for embedded devices is cross-compiled, not compiled on the device itself ;)
[19:12] <burek> you would be surprized :)
[19:12] <JEEBsv> but yes, some people do that from time to time for the lulz
[19:13] <burek> try to cross-compile glib-2.0 for arm and when you go to their support channel and get the answer like "install qemu because we don't have time to help you on issues that qemu already solved", then you'll know what i mean :)
[19:14] <JEEBsv> ^^;
[19:14] <burek> anyway, i was lucky gstreamer had those plugins, otherwise i would most probably abandon entire idea
[19:14] <burek> so, i think it would be cool for ffmpeg too, but only if it's not too much of work
[19:15] <JEEBsv> yeah, it probably atm would be a bit too much work :/
[19:15] <JEEBsv> would be nice tho, in theory
[19:15] <burek> well, life's great already then :)
[19:53] <Prottey> which profiles does internal aac coder support as for now?
[20:29] <JEEBsv> Prottey: only what's in LC-AAC afaik
[20:39] <nevcairiel> en or decoder?
[20:40] <JEEBsv> coder so I would guess he meant encoder
[20:40] <JEEBsv> but not like I know
[20:42] <Prottey> yes, encoder
[20:43] <Prottey> what is about mpeg-4 als?
[20:43] <Prottey> is it already supported?
[20:45] <JEEBsv> Prottey: http://ffmpeg.org/general.html#Audio-Codecs
[20:45] <JEEBsv> have a list
[20:50] <cone-868> ffmpeg.git 03Michael Niedermayer 07abe68364a321: swfdec: check space before copy
[20:50] <cone-868> ffmpeg.git 03Michael Niedermayer 07a9456c7c5ca8: mjpegdec: tighten unescaped_buf_size size check, prevent null ptr deref
[20:50] <cone-868> ffmpeg.git 03Michael Niedermayer 070e239b22dbbe: xan: check size_segment before reading, fixes out of array read.
[22:34] <cone-868> ffmpeg.git 03Clément BSsch 077581ad24a924: lavc/aac: fix shared build failures with MSVC.
[22:56] <ubitux> michaelni: Carl asked me to add a no GPL fate box, so i enabled the test on that box; fate will likely turn yellow, no worry.
[23:08] <cone-868> ffmpeg.git 03Michael Niedermayer 077ab690bf5f4b: indeo4: more complete check for the scan vs block sizes.
[23:08] <cone-868> ffmpeg.git 03Michael Niedermayer 070a373c31cb7f: svq1dec: dont export the qscale table.
[23:54] <ubitux> nevcairiel: is there any other problem preventing from having a shared/dll msvc instance?
[00:00] --- Tue Nov 13 2012