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

[burek]

[00:25] <ubitux> nyuhu: i don't remember exactly, but don't you need to get it yourself with ff_get_video_buffer() or something?
[00:27] <ubitux> nyuhu: it might be needed automatically allocated when you don't have a start_frame() callback
[00:27] <ubitux> s/needed//
[00:29] <ubitux> isn't what you did in the smartblur filter actually?
[02:00] <CIA-52> ffmpeg: 03Michael Niedermayer 07master * r0b23452c01 10ffmpeg/libavcodec/ffv1.c: 
[02:00] <CIA-52> ffmpeg: ffv1: fix 2 uninitialized variable warnings
[02:00] <CIA-52> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:00] <CIA-52> ffmpeg: 03Michael Niedermayer 07master * r5d55830388 10ffmpeg/libavcodec/snowdec.c: 
[02:00] <CIA-52> ffmpeg: snowdec: remove unused variable
[02:00] <CIA-52> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:22] <nyuhu> ubitux : yes it was that, I realized it by looking at the default start_frame callback, thx
[02:22] <nyuhu> ubitux : in smartblur I implemented the end_frame() callback ;)
[11:50] <saste> ecaping is always a bitch
[12:47] <ubitux> saste: hey :)
[12:48] <ubitux> saste: missing closing ']' around "[- at var{END}"
[12:49] <saste> ubitux: please reply by email, so I won't discard to fix it when doing the next reply
[12:49] <ubitux> ok ok
[12:50] Action: Daemon404 doesnt think he actually got to talk to ubitux at vdd -- talkesto beastd tho
[12:50] <ubitux> yeah i didn't met you
[12:50] <ubitux> as i said, i mostly stayed in a corner of a room
[12:50] Action: Daemon404 was the only one with both FFmpeg and libav on his name tag
[12:51] <ubitux> Daemon404: really?
[12:51] <Daemon404> i think so.
[12:51] <ubitux> were you the guy saying you wouldn't want to choose between the two?
[12:51] <ubitux> when choosing between two rooms or something
[12:52] <ubitux> or was he victor?
[12:52] <Daemon404> could have been either
[12:52] <Daemon404> i eventually went to libav, as it had stuff about msvc which i was involved in
[12:52] <Daemon404> and such
[12:52] <ubitux> :)
[12:53] <Daemon404> were you there for dinner and stuff?
[12:53] <ubitux> nope
[12:53] <saste> anybody willing to write a short report from VDD?
[12:53] <ubitux> not the dinner
[12:54] <ubitux> here is my report: "ubitux was here"
[12:54] <saste> just about what was discussed, who was present, how people was dressed and so on
[12:54] <Daemon404> the talks were streamed 
[12:54] <Daemon404> the discussions werent tho
[12:54] <saste> yes i see part of them, thanks to wbs
[12:55] <saste> kostya's talk was great
[12:55] <Daemon404> ;p
[12:56] <Daemon404> http://lists.libav.org/pipermail/libav-devel/2012-September/034643.html
[12:57] <Daemon404> kind of a high level overview of the libav room
[12:58] <saste> Daemon404: yes I read that
[12:58] <ubitux> with Nicolas and Alexander, we mostly talked about how we should store the styles in the next avsubtitle struct
[12:59] <ubitux> like how to deal with storing a CSS abstract tree
[12:59] <Daemon404> for webvtt?
[12:59] <ubitux> and how to match classes and stuff
[12:59] <ubitux> Daemon404: for the overall infrastructure of subtitles
[12:59] <Daemon404> well yes
[12:59] <Daemon404> but css is specific to webvtt
[12:59] <ubitux> the question was about how to store all the css supports
[13:00] <ubitux> assuming it's able to represent any potential styling design
[13:00] <Daemon404> libwebkit
[13:00] Action: Daemon404 runs
[13:00] <ubitux> anyway, we mostly conclude that it was a nightmare and went home
[13:00] <Daemon404> sounds about right
[13:00] <ubitux> we need to do something for this anyway
[13:01] <ubitux> not only for webvtt actually
[13:01] <ubitux> but we want to store the styles of ASS in an AST instead of a string for instance
[13:01] <ubitux> so we can encode them "easily"
[13:02] <ubitux> anyway, about vtt i started to write a demuxer
[13:02] <Daemon404> AST for subtitles...
[13:02] <ubitux> i'll try to get it done in the next days
[13:02] <Daemon404> boy i am glad i do have to touch this
[13:02] <ubitux> Daemon404: do you know how the ASS ’ SRT styling works now in FFmpeg?
[13:02] <Daemon404> nope.
[13:03] <ubitux> or more generally the "Any" ’ SRT
[13:03] <ubitux> well
[13:03] <ubitux> "Any" is decoded to ASS markup, because it supports most of any subtitle styles
[13:03] <ubitux> (so as a ASS markup string)
[13:03] <ubitux> and then the subrip encoder just convert that markup string into nested subrip tags
[13:04] <Daemon404> fun
[13:04] <ubitux> that actually kind of works and it's nice
[13:04] <ubitux> but it's not easy to extend this stuff to any convert
[13:05] <ubitux> cause parsing a ASS string markup in an encoder is kind of more complicated than browsing an AST
[13:05] <Daemon404> indeed
[13:05] <Daemon404> right.
[13:05] <ubitux> the thing is, storing an AST of styles is a nightmare
[13:05] <Daemon404> also
[13:05] <ubitux> and styling of events as well
[13:06] <Daemon404> saste, chrome room can be summed up as following: 1) "i cannot say or speak for google, and i have no info on what you ask" (no answers) 2) chrome guys trolling libav about not switching to libav
[13:06] <Daemon404> summary #1 ^
[13:06] <Daemon404> oh and 3) setting up fate bots with google's special tools
[13:06] <ubitux> trolling libav about not switching to libav?
[13:07] <Daemon404> yes
[13:07] <ubitux> oh ok
[13:07] <ubitux> troll to why they don't switch to libav?
[13:07] <Daemon404> yes
[13:07] <ubitux> Daemon404: was that because of the ogg stuff?
[13:08] <saste> why don't they switch to themselves?
[13:08] <ubitux> or maybe security?
[13:08] <Daemon404> no
[13:08] <Daemon404> "it costs money to change. give us a valid reason."
[13:08] <Daemon404> shit - fan
[13:08] <Daemon404> lulz ensue
[13:08] <ubitux> ok
[13:08] <Daemon404> etc
[13:08] <ubitux> sounds legit
[13:09] <ubitux> saste: the captionning stuff on sunday was interesting
[13:10] <ubitux> the main thing was that webvtt is meant to be the standard subtitle format for anything, and want to be used widely, but isn't really designed for anything than the web
[13:10] <ubitux> (CSS style, not obvious how to mux it in media containers, etc)
[13:11] <saste> the name says it all: web VTT
[13:11] <ubitux> yeah but well& it won't be limited to web
[13:11] <ubitux> since it will be muxed in webm
[13:11] <saste> ubitux: what about relying on some external libwebbloat?
[13:12] <ubitux> that means it will be a hard dependency
[13:12] <Daemon404> not gonna lie
[13:12] <ubitux> (if we want to store an exploitable-by-encoder AST, we would use libwebbloat)
[13:12] <Daemon404> i kinda cringed during the webvtt talk
[13:12] <saste> only for the component which uses it
[13:13] <ubitux> saste: the component will be all the text subtitles encoders and decoders
[13:13] <ubitux> 'cause enc & dec would output that AST in the subtitles struct
[13:13] <ubitux> and that means the api user would need that libwebbloat
[13:14] <ubitux> which is a problem
[13:14] <saste> ah shit
[13:14] <saste> time to write ffirefox
[13:14] <ubitux> fffufufu
[13:30] <merbanan> Daemon404: I had that to
[13:32] <Daemon404> merbanan, ah
[13:41] <Compn> 3DNow -> KILL, poor diego
[13:41] <Daemon404> we held a vote.
[13:42] <Daemon404> kill it when it gets in the way, otherwise, leave sleeping things lie
[13:42] <Daemon404> s/leave/let/
[13:43] <av500> a vote?
[13:43] <av500> we are voting again?
[13:43] Action: av500 forks the project
[13:43] <Daemon404> lol
[13:43] <ubitux> :)
[13:43] Action: Compn argues about counting votes incorrectly due to hanging chads
[13:44] <Daemon404> Compn, shouldnt have used a butterfly ballet
[13:45] <ubitux> saste: i think you forgot to address the "break" comment in case of quote=1 in the csv escaping patch
[15:00] <burek> what is the proper way to change the brightness of the video, using ffmpeg?
[15:07] <saste> burek: we have the mp=eq/eq2 filters
[15:08] <saste> we're going to port them to native filters
[15:11] <cbsrobot-> burek: you could also use the lut filter 
[15:12] <cbsrobot-> lutrgb="r=1.1*val:g=1.1*val:b=1.1*val" <- to get a brighter image
[15:12] <cbsrobot-> lutrgb="r=.9*val:g=.9*val:b=.9*val" <- to get a darker image 
[15:16] <burek> I see
[15:16] <burek> thanks a lot
[15:16] <burek> a guy was asking that on the forum and I just realized I haven't even saw something like that in the documentation
[15:16] <burek> seen* :)
[15:18] <saste> burek: simpler => lutyuv=y=val*1.1
[15:19] <saste> but eq should be more specific
[15:19] <saste> we could even implement GUI filters for setting equalization params on the fly
[15:20] <burek> saste, you mean like 'q' key, that would be interactive or something?
[15:20] <saste> burek: no I meant a GUI with knobs/switches
[15:21] <burek> when did ffmpeg start gui branch? :)
[15:21] <saste> the filter creates a GUI window with the controls
[15:21] <burek> or you are talking about mp
[15:21] <saste> the controls send commands to the filtergraph, and are processed by the filters
[15:21] <saste> no i'm talking about ffmpeg
[15:22] <burek> but what about non-gui servers
[15:24] <saste> well you can't even instantiate the gui-filter if you don't have a graphical environment
[15:24] <cbsrobot-> saste: would be nicer to be able to specify the values directly on the command line
[15:25] <saste> cbsrobot: sendcmd
[15:25] <cbsrobot-> yes I saw it
[15:25] <saste> and now it is already supported,  though not documented
[15:25] <saste> ffmpeg reads from stdin the commands to inject
[15:25] <saste> also it is ffmpeg-specific, while sendcmd is more generic
[15:26] <cbsrobot-> sometimes its nicer to use a shorter syntax
[15:26] <cbsrobot-> lutyuv=y=1 at 1,2 at 100,1 at 300
[15:26] <cbsrobot-> or soemthing similar
[15:27] <saste> cbsrobot-: from the POV of the developer (aka me) that involves a lot of logic/maintainance duplication
[15:28] <cbsrobot-> saste: np - patches welcome, I know
[15:28] <cbsrobot-> we discussed it a few months back already &. 
[15:29] <cbsrobot-> just put it in front of the guy TODO - ok ?
[15:29] <cbsrobot-> *gui
[15:29] <saste> the gui guy
[15:29] <saste> the gui gay guy
[15:29] <saste> and so on...
[15:30] Action: saste is childish
[15:32] <burek> I'm getting a raspberry pi soon, and first thing I'm gonna do is to build ffmpeg for it :)
[15:32] <burek> can't wait to see how will it work :)
[15:36] <thresh> I guess here is a better place
[15:36] <ohsix> the audio output is bad and it's in a broadcom blob so you can't fix it
[15:37] <thresh> Daemon404: so I think it'd be fine for VLC if we had '--disable-all --enable-postproc' or something for ffmpeg build; what's your take?
[15:38] <michaelni> thresh, if you are completely against the full checkout issue then the libpostproc repo could be made R/W and i could give Daemon404 write access so everyone can maintain it on videolan and theres no mirror no access problem
[15:38] <thresh> I don't know if Daemon404 likes maintaining it on videolan also; I have nothing against that, though.
[15:39] <michaelni> but it will then mostly depend on Daemon404 to maintain it as i am not a fan to rebase all commits from ffmpeg 
[15:40] <thresh> well, currently it's exactly like that
[15:40] <thresh> he picks the relevant commits, pushes them to his repo on github
[15:40] <thresh> then a cronjob on videolan server fetches them
[15:41] <michaelni> currently noone has write access to the repo, which is worse
[15:41] <michaelni> consider thgeres a security bug and Daemon404 is unavailable
[15:43] <thresh> indeed
[15:43] <thresh> well, here is the problem: if I add r/w access, I need to remove the cron job; that means someone has to actually push the changes, so if Daemon404 is okay pushing to both github and videolan, it will work
[15:46] Action: Daemon404 is confused as to what is going on
[15:46] Action: michaelni is confused too
[15:48] <michaelni> anyway, my point is that i would prefer that there where no seperate repo and someone would just make sure libpostproc can be build standalone from ffmpeg, but
[15:48] <michaelni> iam happy too if theres a seperate libpostproc repo that i (better all ffmpeg devels) have write access to in case of some emergency
[15:49] <Daemon404> i do not care either way <_<
[15:49] <thresh> Daemon404: so you won't continue updating your github fork?
[15:50] <Daemon404> its simple to make it mirror videolan.
[16:04] <michaelni> Daemon404, its your choice what you prefer as you would be the one doing the maintaince in the seperate repo
[16:05] <michaelni> do you prefer libpostproc repos to die and it be buildable from main ffmpeg standalone or a repo that everyone has access to but that someone(you likely) has to maintain
[16:07] Action: michaelni just vounteers to maintain a libpostproc inside ffmpeg or a clone of libpostproc that can be updated with git merge easily
[16:09] <michaelni> clone of FFMPEG
[16:10] <Daemon404> i have no strong opinion either way
[16:11] <michaelni> well we have to choose one :)
[16:11] <michaelni> i prefer it inside ffmpeg, thresh prefers a seperate repo
[16:12] <michaelni> there are technical arguments for both and against both
[16:16] <michaelni> Daemon404, if you cant decide, then ill leave it to thresh to decide which of the 2
[16:16] <Daemon404> thats fine
[16:16] Action: Daemon404 is leaving very soon..
[17:31] <kriegerod> could somebody please look at this bug https://ffmpeg.org/trac/ffmpeg/ticket/1713 - when asm is enabled, particular usage of static libs is impossible on x86_64
[17:51] <ubitux> kriegerod: can you try with the optimizations?
[17:51] <ubitux> we had some recent issues with --disable-optimizations
[17:55] <kriegerod> ubitux: with --enable-optimizations --enable-asm (and the rest the same) it fails equally
[18:06] <michaelni> kriegerod, make sure you use the same flags when linking the .so as done when the .so libs would be build
[18:07] <michaelni> thresh, if you prefer a seperate repo over building libpp standalone from ffmpeg-git then please make the repo r/w accessable to ffmpeg again. ill give Daemon write access as soon as i have his public ssh key
[18:08] <michaelni> s/Daemon/Daemon404/
[18:09] <kriegerod> michaelni: sorry? could you check by yourself the short test script i put into bugreport?
[18:11] <ubitux> kriegerod: i think michael wants you to compare the build flags with --enable-shared vs --enable-pic 
[18:13] <kriegerod> you mean to add --enable-shared? trying...
[18:14] <kriegerod> doesn't work either
[18:14] <michaelni> kriegerod, i dont have "/usr/local/src/ffmpeg_for_reloc_bug_test" on my system
[18:14] <kriegerod> that's just a path to workcopy
[18:15] <kriegerod> you can set it
[18:15] <kriegerod> to path to workcopy you can use
[18:20] <michaelni> kriegerod, you need  -Wl,-Bsymbolic
[18:27] <kriegerod> michaelni: wow, it works. Thanks a lot.
[18:39] <thresh> michaelni: sure, will do it tomorrow.
[18:42] <michaelni> thresh, ok thanks
[20:44] <Mavrik> um, where do I upload a video to file with a bug report?
[20:48] <Compn> Mavrik : ftp://upload.ffmpeg.org/incoming
[20:49] <Mavrik> thank you
[22:06] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20120903185652&slot=x86_64-archlinux-gcc-valgrind
[22:07] <ubitux> Daemon404: any idea what could have cause this? ^
[22:22] <michaelni> ubitux, Daemon404 this happens as the mmx2 code reads  [-1]
[22:44] <CIA-47> ffmpeg: 03Michael Niedermayer 07master * r8cc77646c0 10ffmpeg/libavfilter/vf_yadif.c: 
[22:44] <CIA-47> ffmpeg: yadif: remove unused variable
[22:44] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:44] <CIA-47> ffmpeg: 03Michael Niedermayer 07master * re6dc0da504 10ffmpeg/libavformat/rmdec.c: 
[22:44] <CIA-47> ffmpeg: rmdec: remove unused variable
[22:44] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:50] <saste> michaelni: are you ok with the transpose patch?
[22:50] <saste> the plan is to remove mp=rotate once I port that feature
[22:51] <saste> then we should try to generalize that feature
[23:01] <michaelni> saste, should be ok, the "dir" field needs its dox updated though
[23:01] <saste> ah yes, forgot to send the updated patch
[23:02] <ubitux> saste: inlink->w, inlink->h, inlink->w, inlink->h
[23:02] <ubitux> don't you need some outlink instead?
[23:04] <ubitux> saste: what is that passthrough btw?
[23:05] <saste> ubitux:  inlink->w, inlink->h, inlink->w, inlink->h... what's that?
[23:05] <ubitux> the av_log in the transpose patch
[23:08] <ubitux> +                   "w:%d h:%d -> w:%d h:%d (landscape passthrough mode)\n",
[23:08] <ubitux> +                   inlink->w, inlink->h, inlink->w, inlink->h);
[23:09] <ubitux> i think you want inlink->w, inlink->h, outlink->w, outlink->h
[23:09] <ubitux> or maybe not?
[23:10] <saste> ah ok, makes no difference since inlink->w == outlink->w in that case
[23:11] <ubitux> and inlink->h == outlink->h?
[23:29] <CIA-47> ffmpeg: 03Michael Niedermayer 07master * rc868219c9a 10ffmpeg/libavcodec/ (Makefile motion-test.c): 
[23:29] <CIA-47> ffmpeg: lavc: put motion test back.
[23:29] <CIA-47> ffmpeg: While not that usefull, we can as well keep it until it breaks.
[23:29] <CIA-47> ffmpeg: When it breaks for whatever reason ill likely remove it
[23:29] <CIA-47> ffmpeg: Sorry for the revert spam, i had not realized this code compiles
[23:29] <CIA-47> ffmpeg: and works fine.
[23:29] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:29] <CIA-47> ffmpeg: 03Michael Niedermayer 07master * r507d2d28d6 10ffmpeg/libavcodec/lsp.c: 
[23:29] <CIA-47> ffmpeg: lsp: change assert to av_assert
[23:29] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:59] <CIA-47> ffmpeg: 03Michael Niedermayer 07master * r1fa4018e29 10ffmpeg/libavcodec/mjpegdec.c: 
[23:59] <CIA-47> ffmpeg: jpegdec: try to fix different flipping behavior of inteljpegs.
[23:59] <CIA-47> ffmpeg: This may need some trial and error to find exactly how to identify them
[23:59] <CIA-47> ffmpeg: so please report any intel jpegs that get fliped wrong.
[23:59] <CIA-47> ffmpeg: Fixes Ticket511
[23:59] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:00] --- Tue Sep  4 2012