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

burek burek021 at gmail.com
Thu Jan 31 02:05:03 CET 2013


[00:16] <saste> is Rob Sykes on IRC?
[00:23] <michaelni> no idea
[00:49] <Compn> name doesnt sound familiar saste , but i could be wrong
[00:49] <Compn> there used to be a sykes i think that came in here
[00:50] <Compn> dunno if same person
[00:50] <saste> Compn, he helped with the soxr thing in libswr
[00:50] <saste> he also contributed to the wiki IIRC
[00:50] <saste> at first I believed he was Skyler_ 'cause the assonance
[00:51] <cone-913> ffmpeg.git 03Carl Eugen Hoyos 07master:3c3d68a97677: Fix 1bpp palettized png with width not a multiple of 8.
[00:57] <wm4> wow png is complex
[01:03] <Compn> the real question is, does anyone use ffmpeg for image processing :P
[01:03] <Compn> not talking about film tiffs either
[01:08] <wm4> Compn: I bet converting image<->video is pretty common
[01:11] <saste> Compn, the question is, why not?
[01:11] <saste> video processing is just a generalization of image processing
[01:12] <Compn> i know :)
[01:15] <cehoyos> saste: I still believe it would be much more important to get hands on a failing sample than more unreproducible reports about aresample...
[01:18] <llogan> saste: what about Rob Sykes? i was in contact with him about a libsoxr package in Arch user repo
[01:19] <saste> llogan, i asked if he was on IRC, he could review the filters from durandal since he's the author of the ported code
[01:20] <llogan> oh. i see. you could always email him via the address in his code. he seemed nice enough.
[01:33] <llogan> why did fflogger re-repeat my wiki edits?
[01:34] <michaelni> llogan, ask burek
[01:44] <llogan> ot: anyone here like/use linode?
[01:47] <llogan> my old server is old and i don't need a dedicated/physical server anymore...
[02:52] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:4d3d36254959: dirac/x86: fix compile without inline asm
[04:48] <Compn> https://aws.amazon.com/elastictranscoder/
[04:49] <Compn> anyone contact amazon bout ffmpeg? :P
[04:51] <wm4> Compn: can ffmpeg use the cloud?
[05:02] <Compn> wm4 : thats the point. i've bet they've modified it to use the cloud 
[05:06] <wm4> oh, so you just want to play GPL police
[05:26] <Compn> lol
[05:27] <Compn> wm4 : since amazon isnt distributing thier encoder, there isnt much to police gpl wise
[05:27] <Compn> asking nicely for changes never hurt anyone
[05:28] <wm4> switch to AGPL
[06:53] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:71f8d7045638: dirac/x86: fix compile without yasm
[07:14] <leo2013> hello
[07:14] <leo2013> I'm trying to write one encoder for h264 on hardware in ffmpeg.
[07:14] <leo2013> and confused by the time stamp as the ffmpeg flow.
[07:14] <leo2013> I use the decoder's value for outputs: "pkt->pts = frame->pkt_pts; pkt->dts = frame->pkt_dts;"
[07:14] <leo2013> but not correct.Who could give some suggentions,thanks!
[07:15] <leo2013> so confused about how to add the time stamp one frame after one frame.
[10:06] <cone-913> ffmpeg.git 03Peter Ross 07release/0.11:155a0bed9722: wtvdec: demux thumbnail picture to AVStream.attached_pic
[10:06] <cone-913> ffmpeg.git 03Peter Ross 07release/1.0:4f8b7eb87f64: wtvdec: demux thumbnail picture to AVStream.attached_pic
[10:07] <cone-913> ffmpeg.git 03Peter Ross 07release/1.1:54e19092fd60: wtvdec: demux thumbnail picture to AVStream.attached_pic
[10:31] <cone-913> ffmpeg.git 03Carl Eugen Hoyos 07master:91f359292a52: Correctly mark non-default streams when muxing matroska.
[11:00] <kierank> Compn: they distribute ffmpeg to customers
[11:00] <kierank> oh wait they don't
[11:00] <kierank> never mind
[11:00] <kierank> i thought you get a vm in the cloud
[11:00] <kierank> affero gpl would be rather comical for me
[13:04] <ubitux> hey
[13:04] <ubitux> got some little free time, any stuff i should look at in priority?
[13:08] <wm4> ubitux: just now there were some subtitle crash tickets
[13:11] <ubitux> doesnt sound fun :(
[13:11] <ubitux> but ok
[13:12] <ubitux> 404, and it's not a crash
[13:13] <Compn> ubitux : i have a subtitle that mplayer cannot display properly , i think its a strange encoding if you want to take a look :P
[13:13] <Compn> or uh
[13:13] <Compn> theres a stereo3d patch
[13:13] <Compn> to add another red/blue color
[13:13] <ubitux> utf16?
[13:13] <Compn> possibly
[13:13] <ubitux> can i have a look to the sub?
[13:14] <Compn> ubitux : http://www.datafilehost.com/download-9885ce69.html
[13:14] <Compn> or i can put it in incoming
[13:15] <Compn>  "Cloud Atlas (2012).srt"
[13:15] <Compn> is in incoming
[13:15] <ubitux> wait wat is this
[13:15] <ubitux> :D
[13:15] <ubitux> hahaha the tags are encoded too
[13:15] <Compn> i have no idea, but its so broken i couldnt figure it out
[13:15] <ubitux> that's awesome
[13:16] <Compn> i just told the user to download a different .srt file :)
[13:16] <ubitux> that's actually very interesting :)
[13:17] <Compn> can iconv handle it? i dont have it installed ...
[13:17] Action: wm4 should try to get rid of subreader.c
[13:17] <Compn> wm4 : get libass to take all that code? :P
[13:17] <Compn> wm4 : or use ffmpeg parsers ?
[13:18] <wm4> Compn: I doubt ibass wants to do it
[13:18] <wm4> so, ffmpeg
[13:18] <Compn> obviously libass wont do it
[13:18] <wm4> but what about libav users...
[13:18] <wm4> well it could
[13:18] <ubitux> Compn: don't you get something with -utf8 with mplayer?
[13:19] <Compn> wm4: you could submit patch to libav from ffmpeg
[13:19] <ubitux> Compn: there is an utf8 bom in the file
[13:19] <av500> yep
[13:19] <Compn> ubitux : oh that works
[13:19] <av500> so assume utf8
[13:19] <wm4> Compn: backporting all that stuff is a lot of effort
[13:19] <ubitux> Compn: you'll get some trouble with the tags i believe though
[13:19] <Compn> be nice if it were autodetected
[13:20] <Compn> wm4 : wont work as just one big patch huh?
[13:20] <ubitux> haha like ffv1?
[13:20] <wm4> definitely not
[13:20] <ubitux> it works if it's from ffmpeg
[13:21] <ubitux> it won't if it's original work
[13:21] <ubitux> (see BBB fighting with Diego recently)
[13:21] <Compn> lol
[13:21] <ubitux> if it's some stuff from ffmpeg you can squash them altogether
[13:21] <wm4> lol?
[13:21] <ubitux> "it's crap anyway"
[13:22] <ubitux> wm4: don't you remember all the ffv1 commits squashed in libav?
[13:22] <wm4> so libav is less strict with massive backport patches from ffmpeg?
[13:22] <wm4> no
[13:22] <ubitux> see 0f13cd3187192ba0cc2b043430de6e279e7b97c3
[13:22] <wm4> wasn't aroind
[13:22] <ubitux> that commit is awesome
[13:23] <ubitux> there is like 20 commits in one
[13:23] <Compn> thats my understanding that libav doesnt do 'histories' from ffmpeg ...
[13:23] <Compn> as long as you clean up a patch to get it in libav (unless they decide to just rewrite the whole thing and make another api)
[13:23] <wm4> nice
[13:24] <Compn> which is what they did instead of taking libswsresample iirc
[13:24] <ubitux> you just have to make sure the codng style is correct
[13:24] <ubitux> if the coding style is correct, then it's certainly good code
[13:24] <Compn> enough trolling!
[13:24] <Compn> :P
[13:24] <ubitux> yeah
[13:24] <ubitux> sorry :))
[13:25] <wm4> lolol
[13:25] <av500> code is read way more often than written
[13:25] <av500> so style matters
[13:25] <Compn> too bad everyone hates code comments :P
[13:26] <ubitux> av500: so libswresample was rewritten from scratch because of the unreadable coding style?
[13:26] <av500> did I say that?
[13:26] <ubitux> i never implied this
[13:26] <ubitux> i'm asking
[13:26] <wm4> god praise uncrustify
[13:26] <av500> ubitux: I never looked into it
[13:26] <av500> so dont ask me
[13:27] <ubitux> av500: yeah, none of the libav dev did :(
[13:27] <wm4> it's a survival tool when dealing with mplayer code
[13:27] <ubitux> uncrustify has a lot of issues
[13:27] <ubitux> especially with the bad config libav is using
[13:28] <wm4> produces some funny constructs
[13:28] <av500> ubitux: but yes, somebody should run indent over it
[13:28] <ubitux> i don't think it matters
[13:28] <av500> for (ch=0; ch<srcs->ch_count; ch++) {
[13:30] <burek> just to paste the url here before i forget about it, i dont know if the guy has submitted a bug report or not, but he did find some issue related to negative ctts values in ffmpeg: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=778
[13:30] <ubitux> i see no real problem with it, except the inconsistency with some other part of the code base
[13:30] <ubitux> it's not less readable, just different
[13:31] <av500> opinions differ on that I guess
[13:31] <av500> I find it hard to read
[13:31] <av500> but ymmv
[13:31] <av500> still, making an effort to style the code is not wasted
[13:32] <Compn> nevcairiel : is the dxva2 patch still on your list to review ?
[13:32] <ubitux> oh nice the filters from Paul
[13:32] <Compn> just curious, i dont want to bug anyone about it.
[13:35] <burek> just curious about mentioned coding style above, does ffmpeg have any "official" coding style, that could just be applied at entire source code (just like a lot of software companies do), making it irrelevant who writes the code in which fashion
[13:35] <ubitux> that's what Diego has been working on for 10 years
[13:35] <ubitux> ask him
[13:36] <av500> http://ffmpeg.org/developer.html#Coding-Rules-1
[13:36] <ubitux> short answer: yes we have a recommended coding style, no it's not that simple to apply it everywhere
[13:36] <av500> ...The main priority in FFmpeg is simplicity and small code size in order to minimize the bug count.
[13:36] <ubitux> especially when it sometimes makes sense to violate these rules to give more sense to the code
[13:36] <av500> some people mistake "fewer spaces" with "small code size"
[13:40] <Compn> ehe
[13:40] <Compn> http://lists.libav.org/pipermail/libav-devel/2013-January/042729.html
[13:40] <Compn> neat
[13:40] <Compn> basically 'port avisynth filter' request
[13:41] <Compn> and probably 'make ffmpeg filters work in vlc'
[13:44] <burek> ubitux, i see, well, in Eclipse, there is a simple file (a template) that describes all the stuff related to the coding-style, like indent in functions, loops, breaking long lines, etc. So, when you copy paste a bunch of crap in the editor it styles it even automatically for you. Now, I don't know if there is any standalanone (batch) tool that does the similar thing, but it might be worth considering using it
[13:45] <ubitux> it's not that simple
[13:45] <burek> also, those special cases can be marked with special kind of comments, that would tell the tool not to touch that part of the code
[13:45] <ubitux> try to use it with templated code, or simply macro
[13:46] <ubitux> also, you'll start the enternal debate on "a*b + c" more readable than "a * b + c" sometimes
[13:46] <ubitux> also, various vertical align on a lot of stuff
[13:46] <Compn> "pretty printing"
[13:46] <ubitux> sometimes done because it's related data, sometimes not, which an automatic script can't guess
[13:46] <ubitux> and will obviously destroy
[13:46] <ubitux> or make insane
[13:46] <Compn> dont forget, there were cosmetics patches that changed benchmarks/speed :D
[13:46] <Compn> long long ago
[13:47] <burek> well, you agree upon one "standard" coding style pattern and all the small parts of that coding styles, that you could disagree on, could be solved with your own such local tool which will style it like you want
[13:47] <ubitux> yes, and some that broke stuff like we saw in libav several times
[13:47] <Compn> unless i made that up
[13:47] <burek> so everybody is happy
[13:47] <Compn> :D
[13:47] <ubitux> (and which are still unfixed because they don't watch ffmpeg history)
[13:48] <Compn> i miss the days of '10l' 
[13:48] <Compn> :P
[13:48] <ubitux> that still happens at time in ffmpeg history
[13:48] <burek> well ok, but not willing to change things, in order not to break anything, will not get you anywhere except it will stall you
[13:49] <Compn> burek : it will stall the person trying to unify the code, yep
[13:49] <burek> ok, those were just my 2 cents, nothing more :)
[13:49] <Compn> how are you going to not break architechtures you dont own 
[13:49] <av500> if you restyle code, the generated asm should stay identical
[13:49] <Compn> like bfin, mips, etc
[13:49] <av500> thats easy to test
[13:49] <Compn> emulated?
[13:50] <ubitux> av500: not always that easy
[13:50] <Compn> its a slow process, and i'm not against it anyhow, if you want to do it :P
[13:50] <av500> ubitux: ?
[13:50] <Compn> burek : we just like to bikeshed about it :P
[13:51] <ubitux> av500: hint: macro with stuff like __line__, mixed preproc, etc
[13:51] <av500> that will still be compiled
[13:51] <av500> and you can compare asm
[13:51] <ubitux> you need to do various compilations config
[13:51] <ubitux> sometimes
[13:51] <av500> sure
[13:51] <ubitux> which you might not be able to do depending on your config
[13:51] <ubitux> or at least, it can be a pain
[13:51] <ubitux> and most people never do it
[13:52] <ubitux> i'm pretty sure even diego doesn't btw
[13:52] <Compn> ffmpeg (and libav) are getting lots of patches from various companies now
[13:52] <Compn> thats neat
[13:52] <Compn> intel copyrights, google copyrights, nvidia ...
[13:52] <Compn> mips
[13:53] <ubitux> the mips guys are awesome :)
[13:53] <ubitux> they are very productive
[13:53] <ubitux> funny that libav reject them because of "beee inline asm eviiil" btw
[13:53] <ubitux> oups sorry i'm trolling again
[13:53] <JEEB> I think many people within libav facepalmed at that as well
[13:53] <Compn> the mips code isnt in libav ?
[13:54] <JEEB> since afaik there is no other way of doing it >_>
[13:54] <ubitux> Compn: yup :)
[13:56] <j-b> good morgen
[13:57] <Compn> j-b : where are you with libavfilter support? :P
[13:57] <j-b> Compn: I am in Italy :)
[13:57] <j-b> Compn: maybe this is not the right answer, though :D
[13:57] <Compn> doesnt sound ideal for coding...
[13:57] <Compn> :P
[13:57] <Compn> hows the weather ?
[13:58] <Compn> today will be about 20C and tonight will be 0C for me :)
[13:58] <Compn> crazy weather
[14:05] <j-b> Compn: :) I am with Luca, so, maybe we can discuss about this topic.
[14:10] <Compn> ubitux : btw we tried -subcp utf8 not -utf8 . thats why it didnt work in mplayer
[14:10] <Compn> why these options do different things i have no clue :(
[14:11] <Compn> wm4 : maybe you could fix it in your fork :P
[14:19] <michaelni> burek, can you add a feature to fflogger ?
[14:19] <michaelni> i mean something that alerts us when a fate client stoped sending results ?
[14:20] <michaelni> the machines have the tendency to get stuck occasionally
[14:23] <burek> i see
[14:24] <burek> like a timeout or something
[14:30] <burek> how long interval should i set
[14:32] <Compn> burek : 24hours 
[14:32] <Compn> if i had to guess :)
[14:32] <burek> ok :)
[14:32] <Compn> could be 12 hours , i dont know how often some machines do builds
[14:38] <michaelni> it differs between machines how often they do builds
[14:40] <Compn> yeah
[14:42] <michaelni> some run it just twice a day some run the tests in a loop continiously but the loop may contain many tests so still can have significant delay for each individual configuration
[14:42] <michaelni> and most machines wait when theres no new commit since last time
[14:45] <Compn> sounds like this will be hard to code
[14:45] <Compn> unless you put it on the client side to ping 'alive' messages or something
[14:46] <Compn> or make it like rss ?
[14:46] <nevcairiel> just make it a conservative timeout, dont think any machines need more then 24 hours for a new build
[14:46] <nevcairiel> doesnt have to be immediate
[14:46] <ubitux> durandal_1707: nit: be consistent with the usage of struct & typedef
[14:46] <nevcairiel> just so you find machines easier which hang for a prolonged time
[14:46] <ubitux> durandal_1707: typically chan_cache
[14:47] Action: durandal_1707 ignores nits
[14:47] <ubitux> :)
[14:48] <durandal_1707> you mean to caps it?
[14:48] <ubitux> struct chan_cache, typedef ChanCache
[14:49] <ubitux> use only struct, or typedef with anonymous struct, or whatever
[14:49] <ubitux> but if you use the typedef, ChanCache should be use
[14:49] <ubitux> there is a leak in your realloc if it fails
[14:50] <ubitux> the assert proposed by stefano in the switch case makes the code more obvious, and also makes sure the compiler won't warn in some cases (not here, yet)
[14:51] <ubitux> durandal_1707: is it ok to only copy the the pts and not all the other props with the new buffer?
[14:52] <ubitux> (sorry for not doing a proper ml review)
[14:55] <durandal_1707> ubitux: other filters do it
[14:55] <ubitux> ok
[14:55] <ubitux> in the same kind of scenario?
[14:56] <ubitux> anyway, that's a nice patch you sent there
[14:56] <ubitux> no more comment from me
[14:57] <ubitux> i should compare with the biquad filter from ebur128, but i'm too lazy to do it now :)
[14:57] <cone-913> ffmpeg.git 03Luca Barbato 07master:4e0bc996d995: bfin: unbreak compilation
[14:57] <cone-913> ffmpeg.git 03Martin Storsjö 07master:61d36761efda: movenc: Simplify code by using avio_wb24
[14:57] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:afb4bc3d291f: Merge remote-tracking branch 'qatar/master'
[15:02] <durandal_1707> ubitux: how/what would you compare?
[15:03] <ubitux> the implementation, to see if one is more optimal than the other
[15:04] <durandal_1707> nonsense, it is simple formula
[15:04] <durandal_1707> which cant be SIMD optimised AFAIK
[15:05] <ubitux> seems i used a packed method
[15:06] <durandal_1707> feel free to improve it ...
[15:07] <ubitux> ebur128 is a bit particular since you have 2 successive filters 
[15:07] <ubitux> some optim can be done in it to merge them into one, but i didn't look
[15:07] <ubitux> durandal_1707: sure, i was just curious, not blocking in any way
[15:12] <durandal_1707> ubitux: well, you can always optimize specific situation
[15:14] <durandal_1707> the other thing i wondered is to not have separate filters but just one filter with option to change type, but this may not be any more user friendly
[15:14] <ubitux> (nit: the enum should be in caps)
[15:15] <durandal_1707> yes, but i would need to add 3rd arg to my macro
[15:15] <durandal_1707> i hate macros
[15:15] <ubitux> i don't really know
[15:16] <durandal_1707> i think from ms office days ...
[15:16] <ubitux> sounds fine to me with multiple filters
[15:16] <ubitux> the other way around is fine as well :p
[15:17] <durandal_1707> DEFINE_BIQUAD_FILTER(BIQUAD, biquad, ...
[15:18] <durandal_1707> or i would add another macro to map biquad to BIQUAD?
[15:18] <durandal_1707> when i code something, i just ignore such nits, and move on...
[16:31] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:d8a7c4958e5a: mpegvideo_enc: factor expression out
[16:47] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:c2992b705381: msrledec: move output pointer test up
[16:47] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:dbaae33c2c71: msrledec: move loop into switch
[16:47] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:d2e0a276d593: msrledec: merge switches
[16:59] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:32de2831036a: avstring: fix "warning: return discards const qualifier from pointer target type"
[18:21] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:b926cc7834d5: mss3: prevent AC state from becoming invalid in rac_normalise()
[19:51] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:4a2da83a787b: dnxhddec: fix integer overflow / index check
[20:04] <saste> do we support image sizes where size is not a multiple of the chroma subsampling power?
[20:05] <saste> does it even make sense?
[20:06] <durandal_1707> it makes sense to me
[20:06] <durandal_1707> it is just that IIRC we drop last collumn of pixels
[20:08] <saste> would be possible to support odd-sized cropping/padding?
[20:08] <saste> i tend to believe this would not be possible (losslessly)
[20:13] <cone-913> ffmpeg.git 03PaweB Hajdan, Jr 07master:0451ff295a9f: oggparsevorbis: use av_realloc consistently
[20:13] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:033f1644b59a: fixup_vorbis_headers: add missing malloc failure check
[20:29] <barque> when I use ffmpeg to encode theora/OGG videos AvFormatContext->duration comes out bad
[20:29] <barque> Any idea on how to correct this?
[20:30] <barque> is there some other way I can approximate time
[20:30] <barque> more or less
[20:30] <barque> even to the second it's fine
[20:30] <barque> I've used ffmpeg2theora.exe on top of ffmpeg before, but then I get a LOT of "errors" on packet_reads
[20:30] <michaelni> barque, submit a bugreport
[20:30] <barque> and no EOF
[20:31] <barque> michaelni, right but, is there some work around?
[20:31] <barque> I've seen the -t option saying it can transcode time
[20:31] <barque> would that help or something?
[20:32] <michaelni> you can decode the whole video and count the frames
[20:32] <barque> :S
[20:33] <barque> No really would need it initially
[20:33] <barque> timestamps on the packets are spot on 
[20:33] <michaelni> bugreport <---
[20:33] <barque> so decoding the video and reading last time stamp would work
[20:35] <barque> but yeah can't do that
[20:35] <barque> how do you carry over the same header info from the other file?
[20:35] <barque> maybe it can extract from there or something?
[21:21] <durandal_1707> michaelni: is'nt av_realloc when fails leaks memory in 033f1644b59a
[21:22] <durandal_1707> nvm...
[23:16] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:984add64a41c: wma: check byte_offset_bits
[23:21] <cone-913> ffmpeg.git 03Paul B Mahol 07master:10e4905dd9b7: auenc: remove put_au_header() and merge its code into au_write_header
[23:21] <cone-913> ffmpeg.git 03Paul B Mahol 07master:0dcfccaa691b: auenc: strict check for supported codec
[23:24] <durandal_1707> wtf, why suddenly ffmpeg lost bunch of + on g+
[23:27] <wm4> maybe you trolled too much
[23:28] <durandal_1707> i did not trolled at all
[23:51] <cone-913> ffmpeg.git 03Michael Niedermayer 07master:a084884b628f: flashsv: clear blocks array on reallocation
[00:00] --- Thu Jan 31 2013


More information about the Ffmpeg-devel-irc mailing list