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

[burek]

[00:43] <Compn> whats this image_to_j2k thing in the libopenjpeg patch ?
[00:43] <Compn> is it another project? 
[00:43] <Compn> is it lgpl ?
[00:45] <Compn> oh i guess its not much code
[03:12] <cone-106> ffmpeg.git 03Michael Niedermayer 07master:0cecaa9e2edf: ffmpeg: free attachments, fix memleak
[09:43] <burek> are these two image-based? dvb_teletext, dvb_subtitle
[09:51] <nevcairiel> dvbsubs are bitmaps, teletext is text based
[09:52] <burek> ok, thanks
[09:53] <burek> just one more thing, is it possible to copy dvb_subtitle from a random input file into another output file (with completely different video) ?
[09:53] <burek> assuming that it makes sense to do such thing
[09:53] <nevcairiel> i suppose thats possible
[09:54] <burek> cool :)
[09:54] <burek> did i mention lately that ffmpeg is great? :)
[10:42] <wm4> what's with fate
[11:20] <cone-9> ffmpeg.git 03Stefano Sabatini 07master:c91f1f3f926d: ffplay: drop redundant NULL sws_freeContext() check in stream_close()
[11:20] <cone-9> ffmpeg.git 03Carl Eugen Hoyos 07master:90020d7f4bf2: lavf/segment: use correct spelling and value for EXT-X-ALLOW-CACHE tag
[11:50] <DEATH> Is --disable-mmx meant to disable all SSE etc optimizations too? Because --enable-runtime-cpudetect --disable-mmx apparently means that no CPU specific optimizations are in use
[11:51] <nevcairiel> its not necessarily meant to do this, but in practive it sometimes does
[11:51] <nevcairiel> practice*
[11:51] <DEATH> Also my build only needs audio decoders, build issues that I've been having affect video specific code, configure option to disable all video code could be nice (smaller output).
[11:52] <Skyler_> I think --disable-mmx disables all mmx-and-above
[11:52] <beastd> DEATH: did you look at current configure options? you should be able to disable most video stuff
[11:52] <DEATH> Yeah, I do --disable-everything then enable specific decoders I need
[11:53] <DEATH> I got this yesterday:
[11:53] <DEATH> libavcodec/x86/dsputil_mmx.c:2309:14: error: 'gmc_mmx' undeclared (first use inthis function)
[11:54] <DEATH> As far as I can tell it's for motion compensation, so while I don't really have clue about FFmpeg internals, it does not concern my usage case as I'm using FFmpeg to decode AAC+MP3+Vorbis audio only.
[11:55] <DEATH> Tried to remedy by --disable-mmx but that disabled more stuff than I'd like to disable.
[11:55] <beastd> DEATH: ok, i see.
[11:57] <DEATH> With all instruction set extensions disabled, FFmpeg is only as fast as most of the competing decoders :)
[11:57] <DEATH> (On MP3/AAC/Vorbis audio)
[11:57] <beastd> DEATH: your problem looks like a bug to me. so it probably should be fixed.
[11:58] <DEATH> OK, thanks for acknowledging
[11:58] <beastd> maybe the assignment at dsputil_mmx.c:2309 needs just more #if protection ?
[12:00] <beastd> DEATH: AFAICT the sse init has  "&& CONFIG_VIDEODSP"  . would that fix your compile problem? and hopefully run too ;)
[12:02] <beastd> i am just poking around though. i do not know this code well at all. so please do not take my suggestions too serious.
[12:05] <saste> beastd, are you going to work on kerndeint?
[12:05] <saste> ubitux mentioned that you wanted optimize it, so we can drop mp=kerndeint
[12:05] <beastd> saste: i think this is a misunderstanding. i have shown no interest in kerndeint
[12:06] <saste> beastd, ok
[12:06] <beastd> saste: an lavfi version was posted? it was slower thant mpcodecs wrapper?
[12:06] <saste> i think i'll wait for ubitux then, it's not anything like high priority to get rid of mp=kerndeint
[12:06] <beastd> agree
[12:06] <saste> beastd, check the archive
[12:06] <saste> kerndeint is already in
[12:07] <beastd> saste: oh ok. sorry, for my ignorance.
[12:10] <DEATH> Hmm yes looks like it's missing CONFIG_VIDEODSP check in the #if line, compiles fine after adding it:
[12:10] <DEATH> #if (ARCH_X86_32 || !HAVE_YASM) && CONFIG_VIDEODSP
[12:10] <DEATH> c->gmc = gmc_mmx;
[12:10] <DEATH> #endif
[12:10] <DEATH> Thanks for the input.
[12:11] <beastd> DEATH: ok, i will sent on ffmpeg-devel list for discussion/approval
[12:12] <beastd> thanks for reporting and testing
[12:15] <michaelni> burek, can you do something about the FATE-IDLE logger thing ?
[12:15] <michaelni> its 99% nonsense ATM
[12:15] <michaelni> we have only 1 client (haiku) that actually is stuck
[12:16] <michaelni> well, was stuck, i hope it works now again
[12:17] <michaelni> the duron box needs >2days for a cycle, blame valgrind & amd if you like but it is that slow it was not stuck
[12:19] <nevcairiel> imho it should also say the names of boxes which are newly added to the stuck list, the number is not really useful
[13:14] <cone-9> ffmpeg.git 03James Almer 07master:d1511c02f49e: proresdsp: Fix checkheaders
[13:14] <cone-9> ffmpeg.git 03James Almer 07master:13eb9fcf5686: build: Remove superfluous MAKE variable for the build suffix
[13:55] <beastd> DEATH: Just found out that the problem you described was fixed in exactly that way on Fri Jan 25 by Carl Eugen. So no problem with current git master.
[13:55] <beastd> I was actually looking at an older version because I did not notice I was on a topic branch...
[16:11] <saste> michaelni, how do we handle mid-stream frame parameter changes before feeding the filtergraph in ffmpeg?
[16:11] <saste> or don't we handle them at all?
[16:14] <wm4> saste: would it be possible to let the lavfi glue code reconfigure the immediate following part of the filter chain if the frame fed to a filter differs from the config of the previous frame?
[16:14] <wm4> or would that be too complex, or impossible?
[16:17] <saste> wm4: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/153146
[16:20] <wm4> saste: I'd say always cal config, and filters which can handle the change don't reset themselves - does this make sense?
[16:20] <wm4> *call
[16:21] <michaelni> saste, also see -reinit_filter
[16:21] <saste> wm4, please comment on the thread
[16:21] <wm4> marking filters with bit flags seems fragile and complex
[16:21] <saste> wm4, that's why it is an RFC
[16:36] <cone-9> ffmpeg.git 03Michael Niedermayer 07master:cb573f7fbca1: avcodec/x86: Add daniels copyright to the recent gcc->yasm convertions he did.
[16:46] <wm4> how do you know if new metadata has been added during streaming?
[16:52] <JEEB> ubitux, would you have interest in looking at the source code of a renderer for the ARIB B-24 captioning system? :D https://dl.dropbox.com/u/175558/screenshots/tvtest_caption_lol_positioning.png
[16:58] <wm4> how's the source? is it full of japanese comments?
[17:02] <JEEB> haven't really looked at it yet, but it consists of a captions parsing library (that's used by caption2ass as well f.ex.), and then the actual renderer
[17:02] <JEEB> I would guess Japanese Shift-JIS comments tho :)
[17:02] <wm4> lol
[17:09] <cone-9> ffmpeg.git 03Stefano Sabatini 07master:6e32b377bbb5: ffplay: remove pts_ptr argument from audio_decode_frame()
[17:09] <cone-9> ffmpeg.git 03Stefano Sabatini 07master:02af4e9a97cc: ffplay: rename audio_decode_frame() variable "pts" to "audio_clock0"
[17:09] <cone-9> ffmpeg.git 03Stefano Sabatini 07master:c44281906a87: ffplay: remove misleading comment from audio_decode_frame()
[17:09] <cone-9> ffmpeg.git 03Stefano Sabatini 07master:1897109c00a0: lavfi/pad: add support to named options
[17:09] <cone-9> ffmpeg.git 03Dave Rice 07master:3bba91d32d86: doc/syntax: fix frame rate documentation
[17:09] <cone-9> ffmpeg.git 03Dave Rice 07master:fe63f3d301cc: doc/syntax: add missing frame sizes
[17:34] <cone-9> ffmpeg.git 03Michael Niedermayer 07master:4d37d2bfc53c: put_vp_no_rnd_pixels8_l2_mmx: fix type
[17:57] <durandal_1707> divVerent: mutt messed up patch somehow, you should use git send-mail instead
[17:59] <wm4> so I heard mp4 file always have a perfect index that contains the timestamp for each frame (I don't know mp4,s o this might be wrong)
[18:00] <wm4> doesn't that mean libavformat could set the duration for each packet exactly?
[18:02] <nevcairiel> there is still complications with frame reordering
[18:02] <wm4> oh, right
[18:02] <nevcairiel> but it does provide some duration, not sure where it comes from in mp4
[18:03] <wm4> ah well, I'm mostly interested in an API that doesn't force the player to go haywire when video frames are very sparse
[18:03] <wm4> like it happens with some "slide" videos containing audio and mjpeg frames
[18:03] <wm4> the duration field seems to be mostly unreliable, whatever it is
[18:04] <nevcairiel> most containers just have timestamps, not duration info
[18:08] <cone-9> ffmpeg.git 03Rudolf Polzer 07master:773fc6e0c712: lavfi/showspectrum: set default height to 512
[19:42] <divVerent> 17:57:01 @durandal_1707 | divVerent: mutt messed up patch somehow, you should use git send-mail instead
[19:43] <divVerent> I cannot add my own text when using git-send-email
[19:43] <divVerent> also, it'd use the wrong from address
[19:43] <divVerent> next time I'll just attach the patch as a file then
[19:48] <divVerent> durandal_1707: wtf...
[19:48] <divVerent> [rpolzer at grawp ffmpeg (git)-[master]-]$ git apply ../0001-lavfi-showspectrum-display-multiple-channels-in-sepa.patch 
[19:48] <divVerent> error: patch failed: Changelog:10
[19:48] <divVerent> git-am also fails it
[19:50] <durandal_1707> changelog changed
[19:50] <durandal_1707> the @ somehow become at in your patch ....
[19:56] <durandal_1707> saste: i sent new patch, anxiously expecting your fine review
[20:00] <saste> durandal_1707, thanks
[20:00] <divVerent> 19:50:19 @durandal_1707 | the @ somehow become at in your patch ....
[20:00] <divVerent> durandal_1707: very sure mutt didn't do that
[20:00] <divVerent> maybe the mail archive did?
[20:01] <divVerent> durandal_1707: ah, thanks... this solved the missing link
[20:01] <divVerent> didn't know how to make a named choice
[20:02] <divVerent> and yes, I can still fully sign off on the new patch, great work
[20:08] <saste> bah ffplay -af is growing complicate...
[20:11] <cone-9> ffmpeg.git 03Michael Niedermayer 07master:ccfd8cffe867: qdm2: Fix data type used in multiplication.
[20:11] <cone-9> ffmpeg.git 03Michael Niedermayer 07master:d106679fb526: qdm2: disable superblocktype_2_3==0 code
[20:14] <michaelni> burek, i suggest you disable the FATE-IDLE thing until its fixed, its of no use like this
[20:15] <michaelni> it just prints a random meaningless number every hour
[20:23] <Daemon404> \o/ someone broke ffmpeg's configure
[20:23] <Daemon404> in such a suble, hidden way
[20:23] Action: Daemon404 guess he does a git bisect
[20:30] <durandal_1707> what got broken in configure?
[20:33] <Daemon404> every single math check function
[20:33] <Daemon404> e.g. lrint
[20:33] <Daemon404> instea of: foo(floata,floatb)
[20:33] <Daemon404> int main() { return (int) foo(...): }
[20:33] <Daemon404> it has return 0
[20:33] <Daemon404> which does fuck all
[20:34] <Daemon404> if the compiler has DCE
[20:34] <Daemon404> and i have a feeing the breakage is hidden in a merge commit...
[20:34] <Daemon404> behind wallas of shit
[20:35] <wm4> lol
[20:36] <wm4> maybe ffmpeg devs should send patches to libav instead to make merging easier
[20:36] Action: wm4 runs
[20:41] <divVerent> 20:08:33         @saste | bah ffplay -af is growing complicate...
[20:41] <divVerent> saste: yes
[20:42] <divVerent> ffplay -i lavfi 'amovie=filename.mp3, showspectrum'
[20:42] <Daemon404> what if i have a file named lavfi? ;)
[20:42] <divVerent> we also need a better way for this eventually... preferably by (later) getting rid of ffplay's own copy
[20:42] <divVerent> sorry, -f lavfi ;)
[20:42] <Daemon404> :P
[20:42] <saste> divVerent, not that convenient
[20:43] <divVerent> I agree
[20:43] <divVerent> but that's lavfi
[20:43] <divVerent> that's something to be fixed separately
[20:43] <saste> ffplay IN -af volume=+2dB
[20:43] <divVerent> yes, but an -af cannot create a video stream... or can it?
[20:43] <saste> divVerent, no
[20:43] <divVerent> then maybe that's what is missing ;)
[20:45] <divVerent> ffplay filename.mp3 -filter_complex "[0:0] asplit [a] [va]; [va] ashowspectrum [v]" -map "[a]" -map "[v]"
[20:45] <divVerent> would be great ;)
[20:45] <divVerent> in other words: "consistency with ffmpeg"
[20:46] <divVerent> at least that can be hidden in a shell alias then
[20:51] <saste> divVerent, that's correct in principle
[20:52] <saste> but it's hard to implement in practive, because of the high inconsistencies between the tools
[20:53] <saste> ffmpeg/avconv has lots of specific hacks which have never been ported to the other tools
[20:54] <teratorn> wm4: i think its pretty clear whos making whos job harder, as an outside observer of sorts :))
[20:54] <wm4> teratorn: the interesting question would be whether libav makes merging intentionally harder
[20:55] <teratorn> my answer is to care less i think :/
[20:55] <teratorn> and also to maybe put pressure on debian to repackage ffmpeg
[20:55] <teratorn> since that is just silly
[20:56] <divVerent> saste: I know
[20:56] <divVerent> that this is the issue
[20:56] <divVerent> sort of like mplayer/mencoder, just other way round
[20:57] <divVerent> ffplay has become the neglected stepchild
[20:57] <divVerent> to a point where I wonder if it'd be better to make ffmpeg learn what ffplay can do - i.e. seek
[20:57] <divVerent> anything else already can be done by lavfi :P
[20:58] <wm4> wut, so video playback with ffmpeg+lavd?
[20:58] <divVerent> i.e. if the console, and the video out window of the "sdl" output device would take keyboard input
[20:58] <divVerent> and allow seeking
[20:58] <divVerent> then basically ffplay could be killed
[20:59] <divVerent> oh, possibly AV sync too, possibly in communication between video and audio driver... that sounds ugly ;)
[20:59] <divVerent> but MAYBE both video and audio out syncing to pts would work well enough (for audio this is tricky, though :P)
[20:59] <wm4> how would you do user input and seeking?
[21:00] <divVerent> that's the thing I don't know
[21:00] <divVerent> currently both ffmpeg and lavfi movie source lack seeking support
[21:00] <divVerent> it's just wishful thinking
[21:00] <saste> wm4, input and seeking: you program events (e.g. in lua) which are sent to the filtegraph as events
[21:00] <divVerent> yes
[21:00] <divVerent> THAT half is the easy half ;)
[21:00] <wm4> divVerent: avf_videoplayer? xD
[21:00] <divVerent> we already have this event handling
[21:00] <divVerent> as in, sending commands to the filter graph
[21:01] <saste> divVerent, in the meanwhile i'll add -af to ffplay ;-)
[21:01] <wm4> I'd be careful with this commands and filters thing
[21:01] <divVerent> sure :P
[21:01] <divVerent> not a bad idea either way
[21:01] <wm4> that'll become a mess in no time
[21:01] <divVerent> just, in the long run, PROBABLY ffplay should be killed
[21:01] <divVerent> or maybe replaced by a hardlink to ffmpeg that detects how it should output by binary name ;)
[21:02] <divVerent> but talking the REALLY long run here
[21:02] <saste> and i'm still awaiting for glplay (or in general an opengl output device)
[21:02] <wm4> divVerent: actually I'm glad if "they" can't change their own APIs so easily (due to the code duplication in ffmpeg/ffplay)
[21:02] <divVerent> saste: you SORT of could have it by changing the API from SDL 1.2 o SDL 2 ;)
[21:03] <divVerent> but... don't
[21:03] <wm4> saste: that'd be a good thing, since SDL sucks for video
[21:03] <divVerent> I know how to use SDL 2 so it actually works
[21:03] <divVerent> but it was tricky
[21:03] <divVerent> well, actually, SDL 1.2 also has video surface support
[21:03] <divVerent> but by Xvideo
[21:03] <wm4> saste: you could also display all sorts of pixfmts natively (think 10 bit 444...)
[21:03] <saste> divVerent, what's the status of libsdl2?
[21:03] <divVerent> while SDL 2.0 throws that away and introduces a simplified common 2D interface for OpenGL and D3D
[21:03] <divVerent> can't recommend it yet
[21:03] <saste> what would be the gain for switching from 1.2 -> 2.0
[21:04] <divVerent> I implemented sdl2 output for mpv, and it works
[21:04] <divVerent> but it was tricky
[21:04] <divVerent> OpenGL output, mainly
[21:04] <divVerent> basically, if you DO use sdl2, you WILL hit bugs
[21:04] <saste> the last time I tried libsdl dev tree it was buggy as hell
[21:04] <divVerent> exactly
[21:04] <wm4> they're still changing APIs
[21:04] <divVerent> yes, but not much any more
[21:04] <divVerent> I am reading the ML
[21:04] <divVerent> but, yes, I can't recomemdn it yet
[21:05] <divVerent> I will recommend SDL2 as only output device for ffmpeg the day SDL2 enters Debian stable
[21:05] <divVerent> and that's still like 2, 3 years in the future
[21:05] <wm4> lol
[21:05] <divVerent> I assume SDL2 will be stable by end of the year
[21:05] <wm4> so long
[21:05] <divVerent> given it's now being pushed by app developers for iOS, Android
[21:05] <wm4> they sure are taking their time
[21:05] <divVerent> indeed
[21:06] <divVerent> if the iOS/Android guys wouldn't be already using it for apps they sell
[21:06] <divVerent> we could assume SDL2 will NEVER finish
[21:06] <divVerent> you know, SOMEONE has to push them ;)
[21:06] <divVerent> saste: also, as for SDL2 bugs
[21:06] <divVerent> the HW accelerated outputs are mostly bugfree
[21:06] <wm4> hm does that mean they can use native code easily on android?
[21:06] <divVerent> i.e. opengl, direct3d
[21:06] <divVerent> but the SW output... will cause nightmares ;)
[21:06] <divVerent> if you REALLY want to try tzhat
[21:06] <divVerent> look in mpv source for the APIs I used, and use ONLY these
[21:07] <divVerent> wm4: "sort of" ;)
[21:07] <divVerent> not sure if it's for rooted devices only
[21:07] <wm4> I remember point scaling...
[21:07] <divVerent> just know people ARE making money with it
[21:07] <divVerent> wm4: that's the missing features part
[21:07] <divVerent> but the bugs when you tell SDL a texture is "static!"
[21:07] <divVerent> and it then converts the alpha channel to 1bit RLE...
[21:07] <divVerent> that's awful
[21:08] <divVerent> that's why all textures in mpv are marked and used as dynamic ones
[21:08] <divVerent> even the OSD ones which COULD be seen as kinda static
[21:08] <divVerent> given they tend to update only once per sec
[21:08] <divVerent> (IMHO that's already static enough :P)
[21:09] <divVerent> note: these bugs ONLY happen with the SW renderer. Nevertheless awful.
[21:09] <divVerent> these bugs ALSO quite likely affect the old SDL_Surface API too
[21:09] <divVerent> wonder if SDL 1.2 has these bugs too ;)
[21:09] <wm4> divVerent: the worst for video output, though, is libva
[21:09] <divVerent> given the SW renderer is just a wrapper for SDL_Surface
[21:09] <wm4> well, at least for OSD
[21:10] <Daemon404> oh fuckin boy....
[21:10] <Daemon404> the configure / return 0 problem only happens on msys
[21:10] <Daemon404> FML
[21:11] <Daemon404> and only in ffmpeg
[21:16] <durandal_1707> so when new fate look will finally come in?
[21:18] <michaelni> Daemon404, theres no return 0 in ffmpegs check_mathfunc
[21:19] <Daemon404> yet someone it ends up there
[21:19] <Daemon404> it's mind boggling
[21:19] <Daemon404> somehow*
[21:22] <durandal_1707> so any new filter comming in?
[21:23] <saste> durandal_1707, yours ;-)
[21:24] <saste> you're getting a filter addicted
[21:24] <saste> who's your favourite (git-)pusher?
[21:26] <durandal_1707> i dont have favorite (git-)punisher
[21:32] <durandal_1707> to download vapoursynth source code i need install svn - no way
[21:33] <wm4> use git-svn?
[21:33] <durandal_1707> that needs svn too
[21:34] <wm4> but you don't need to use svn directly
[21:35] <Daemon404> you see, durandal_1707 uses an antiquated OS called BSD
[21:35] <Daemon404> which uses an antiuated system called ports
[21:35] <Daemon404> and this to install svn he needs to invest time
[21:35] <Daemon404> compiling...
[21:35] <Daemon404> compiling....
[21:35] <Daemon404> compiling.....
[21:35] Last message repeated 1 time(s).
[21:35] <Daemon404> etc
[21:35] <durandal_1707> ^troll
[21:36] <durandal_1707> there are nice and smart people with clones on github
[21:36] <Daemon404> none of which are up to date i suspect
[21:36] <durandal_1707> what, why this depens on lav* stuff?
[21:37] <Daemon404> what?
[21:37] <wm4> lav* actually contains a useful video decoder
[21:37] <durandal_1707> i read INSTALL
[21:37] <Daemon404> vapoursynth uses swscale
[21:37] <durandal_1707> ignores lavfi
[21:37] <Daemon404> i think i just died of laughter.
[21:37] <durandal_1707> should be perished into vapour
[21:39] <durandal_1707> now i need to install waf....
[21:39] <wm4> ouch
[21:39] <durandal_1707> this is just too complicated for me....
[21:48] <durandal_1707> michaelni: is it really true that S32 when going to/from planar is converted to float?
[21:48] <durandal_1707> that does not make any sense...
[22:03] <michaelni> durandal_1707, no silly convertions should be done, in what case exactly does this happen?
[22:04] <durandal_1707> dunno, that i read from nicolas reply about reordeing in lavd....
[22:23] <durandal_1707> saste: actually i need to do this from my histogram filter: http://avisynth.org/oldwiki/index.php?page=histogram
[22:30] <saste> durandal_1707, vectorscope?
[22:33] <durandal_1707> all
[23:02] <cone-9> ffmpeg.git 03Dave Rice 07master:71956371a7bb: lavu/parseutils: add digital cinema frame sizes
[23:17] <cone-9> ffmpeg.git 03Stefano Sabatini 07master:cf7b71b0b812: doc/filters: reformat various filter tables items
[23:26] <burek> michaelni, what should i fix about the fate-idle?
[23:26] <burek> do you want to have the names of machines always displayed or something?
[23:27] <nevcairiel> personally i think it would be great if it just names the machine which was just added to the list once, and doesnt list all machines all the time
[23:31] <burek> hmh, i could make a list i guess, but i think it would be easier to have idle time defined for each machine
[23:31] <burek> for example, the default of 24h would be applied to each machines except those configured with a different idle value
[23:32] <burek> that way it wouldnt spam too much
[23:32] <burek> and it would always provide a list of all stuck machines, so you don't have to scroll back and calculate which one is new in the list and if previous ones in the list got unstuck or not, etc
[23:40] <burek> also, which one of these is that "duron box" ? I see a lot of durons in the list, so I don't know for which one to set the idle timeout to > 48h
[23:41] <michaelni> burek, all that say duron 
[23:41] <michaelni> they all run on the same box
[23:41] <michaelni> thats part of the reason why it takes lots of time to finish a cycle
[23:42] <burek> i see
[23:42] <burek> ok, how many hours should i set for timeout then? 72 hrs perhaps?
[23:43] <michaelni> yep
[23:44] <michaelni> or maybe you can automate it
[23:44] <michaelni> like using 24h+average past update time or so
[23:46] <burek> i'll try first 72hrs, just in order not to complicate things if i dont need to
[23:51] <saste> nevcairiel, why RGB -> YUVJ in the showspectrum patch?
[00:00] --- Mon Feb  4 2013