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

[burek]

[00:29] <ubitux> llogan: oh that's quite a bunch of examples you added there :)
[00:29] <ubitux> llogan: don't you think it could make sense to add some predefined presets in the filter instead?
[00:31] <llogan> ubitux: yeah, but i don't know how
[00:31] <ubitux> i guess i could do it
[00:32] <ubitux> llogan: btw, didn't you needed to specify some intensity curve?
[00:32] <ubitux> it seems gimp as such thing, which is additionnal to the colors
[00:32] <ubitux> has*
[00:32] <ubitux> no idea about photoshop
[00:33] <llogan> i only looked at the gimp briefly. i can check again, but the results were very similar to photoshop, as far as i could tell
[00:33] <ubitux> cool
[00:33] <ubitux> how did you get the values btw?
[00:34] <llogan> manually swiped from photoshop. it uses a 0-255 range.
[00:34] <ubitux> ok :)
[00:34] <ubitux> ok well
[00:34] <ubitux> let me add some presets inside the filter
[00:34] <ubitux> that should be handy
[00:35] <llogan> for example, medium contrast is 73/56 163/164
[00:35] <llogan> watch a movie in color negative is interesting
[00:36] <ubitux> you can use -vf negate :P
[00:36] <llogan> it's not the same (i also added "negative" which is like negate)
[00:37] <llogan> also, people can find "negative" if they fail to find negate.
[00:38] <ubitux> what motivated you to play with the filter btw? :)
[00:38] <llogan> lol...
[00:38] Action: ubitux happy to have already one user
[00:38] <llogan> a bad rip of Beastmaster 3 for a "bad movie night"
[00:38] <ubitux> ok :)
[00:39] <llogan> also, it wasn't the GSoC ideas page that i was supposed to work on instead
[00:39] <llogan> i can give you more decimals if you like for more "photoshop" precision
[00:40] <ubitux> i don't think it matters
[00:40] <ubitux> since it's multiplied by 255 after
[00:40] <ubitux> you need enough precision to get back the original int
[00:40] <llogan> numbers aren't my strong point
[00:40] <ubitux> that makes me think it might need some rounding
[00:41] <ubitux> but well
[00:41] <llogan> yeah, i just trunc-ed the originals
[00:42] <llogan> anyway, curves are great. i find them much more useful for color correction than dedicated "color correction" video editor plugins
[00:44] <ubitux> :)
[00:45] <ubitux> i'll send a patch in about an hour
[00:47] <llogan> thanks. i'll let you know if i end up with more presets
[00:48] <llogan> also, Zardoz is weird as shit.
[00:57] <Compnn> one of these days i'll animate an ffmpeg logo using my tablet :)
[01:01] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:01df2a13c32a: avcodec/utils: initialize pixel buffer pool
[01:02] <ubitux> ok got the presets working yay
[01:05] <llogan> ubitux: that was quick. i have to go now, but i'll definitely take a look tomorrow.
[01:05] <ubitux> ok :)
[01:05] <ubitux> i need to update the doc, it's a pain
[01:05] <ubitux> :D
[01:31] <ubitux> strange, the audio path is not tested in the concat filter
[04:10] <Compnn> ubitux : i got some dumb questions...
[04:11] <Compn> ubitux : did you test your ivtc filter on files with bad timestamps? can your filter detect if a file is interlaced or not? what does it do on non-interlaced video? does it distort it?
[04:21] <ubitux> the timestamps should not cause any problems (though i need to fix them in decimate)
[04:22] <ubitux> it's not the purpose of fieldmatching to detect if the file is interlaced or not
[04:22] <ubitux> you can use vf idet for this
[04:22] <ubitux> but it of course has some interlaced metrics in it
[04:22] <ubitux> it shouldn't affect non-interlaced video
[04:22] <ubitux> but i wouldn't recommend to enable it by default if you have this in mind
[04:22] <ubitux> (because sloooww)
[04:27] <Compn> well  thats what i was asking
[04:27] <Compn> i guess
[04:27] <Compn> if it could detect non-interlaced and be faster 
[04:27] <Compn> i'm sure lots of people would like that as a feature
[04:28] <Compn> i know people stick yadif into mplayer configs , and are able to enable/disable it by pressing D key ...
[04:28] <Compn> (i know, different feature, but you get my point)
[04:29] <Compn> people also want autocrop, as long as i'm asking for a pony
[04:34] <ubitux> the main purpose is for encoding
[04:38] <Compn> mixed video with some interlacing and some progressive then
[04:38] <Compn> how about that ?
[04:38] <Compn> :P
[04:38] <Compn> you know... they put that stuff in dvds sometimes
[04:38] Action: Compn just giving ubitux a hard time
[04:44] <ubitux> it will work, it's just not really a good idea for playback imo
[04:45] <ubitux> at least no unconditionnally
[04:45] <Compn> you know users, they dont have good ideas
[04:45] <Compn> but by planning , at least we can help users not shoot themselves in the feet
[04:47] <Compn> anyways patch welcome i'm sure :P
[04:47] Action: Compn goes to troll other people now
[09:51] <pierre-olivierro> Hi all, I'm looking from some informations on how to use the av_packet_new_side_data related API functions to add customized data into video packets.
[09:52] <pierre-olivierro> Got some issues for now with latest FFmpeg versions
[10:56] <xlinkz0> if anyone can help i'd greatly appreciate it : http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1088
[11:54] <michaelni> xlinkz0, does this happen only with ffplay or also ffmpeg & ffprobe ?
[11:55] <xlinkz0> all of them, but i think i figured out the problem, guys at mingw-w64 say it's because SDL is built with -mwindows
[12:04] <michaelni> pierre-olivierro, see the headers and source code, i dont think theres docs elsewhere but what are you trying to do and what issues ?
[12:05] <nevcairiel> oh yeah it could happen if its build as a gui application, which have their stdout turned off
[12:17] <saste> http://bugzilla.libsdl.org/show_bug.cgi?id=1725
[12:21] <highgod> Hi, saste, I submit the opencl patch
[12:21] <saste> highgod, thanks
[12:21] <saste> do you have a link?
[12:22] <highgod> sorry for the mistake I made of the previous patches, it a waste of your time.
[12:22] <highgod> sorry, what is "a link"?
[12:23] <saste> http://bugzilla.libsdl.org/show_bug.cgi?id=1237
[12:23] <saste> but they closed it with no explanation^
[12:24] <nevcairiel> wonder if you can override with -mno-windows
[12:24] <saste> highgod, no problem
[12:25] <saste> i'll try to review the patch tonight
[12:26] <highgod> Thank you very much, if there is anything I can do for the community, I will pleased to help.
[12:26] <saste> highgod, but i agree with michael, there is are security concerns with regards to the access-binary() function
[12:27] <saste> a library should not write files if not explicitely requested, and the read binary files could have been forged by a malignant user
[12:28] <saste> so we may need to devise some mechanism to specify the paths
[12:29] <highgod> ok, but I don't know how to do that,it may different between operation systems
[12:30] <highgod> if the kernels added more and more, it will take a long time to compiles kernels every time
[12:33] <saste> we could create a context for the opencl environment, where we can specify options
[12:34] <highgod> that's good and also for the build-log, which for the error informations of build kernel
[12:35] <highgod> is there any code I can reference?
[12:36] <saste> highgod, check at the end of libavutil/opt.c
[12:37] <saste> contains an example of how it is possible to set options on a context
[12:37] <saste> you could create the context when initing opencl, but this needs some thinking
[12:38] <highgod> should I have to specific the patch that save the binary file? 
[12:39] <highgod> and if run next time, I have to specific the patch of the file and ffmpeg read it?
[12:41] <saste> when you init opencl ffmpeg creates a specific context, which can be accessed some way
[12:41] <saste> then you could set the path to be read when looking for opencl binary files
[12:41] <saste> and the build log file
[12:44] <highgod> Yes, I agree with you, and I just read the mail Michael replied about this problem
[12:55] <highgod> Can we think about just runing opencl without using the binary file? Because the important thing is run OpenCL code at this stage. and the other optimize code can be added later.  
[12:57] <saste> highgod, sure, that can be done in a second step
[13:02] <highgod> and the kernels is just deshake in this step, it doesn't take a long time to compile
[13:03] <highgod> OK, I have little experence on linux things, so about the path setting, maybe I will ask a lot of questions,hehe
[13:04] <saste> highgod, it's not linux specific, the same security concerns apply to windows as well
[13:05] <saste> about the specific path for the compiled opencl binaries, yes that may be OS dependent
[13:06] <highgod> @saste, thanks, we didn't think about it before, our other project just implement like this,hehe.
[13:29] <pierre-olivierro> michaelni: I just want to add some uint8_t values, for customize a little the video stream. I think i'm using functions correctly, but when writing packets, side data seems not to be taken into account
[13:54] <michaelni> pierre-olivierro, customize ? are you sure side data is what you want to use ?
[13:55] Action: michaelni wonders where cone is again
[14:13] <pierre-olivierro> michaelni: yes, i want to add specific data to each video frame, how can I do it without using side data ?
[14:14] <pierre-olivierro> michaelni: and a few version ago, it was working like this.
[15:02] <michaelni> pierre-olivierro, it probably stoped working due to ubitux changes to side data split/merge for muxers but iam not sure if how you use side data is a good idea
[15:06] <pierre-olivierro> michaelni: ok. So if y want to add some other data in a stream, per video frame, how can i do this ? (without using another stream in the container)
[15:07] <durandal_1707> michaelni: your compiler does not dump warnings?
[15:09] <michaelni> durandal_1707, which warning ?
[15:10] <durandal_1707> yop one
[15:10] <durandal_1707> void function which should not be void
[15:12] <michaelni> oops, ill fix in a moment
[15:16] Action: michaelni looks and still sees no cone
[15:17] <michaelni> pierre-olivierro, metadata but this likely will only work with some containers
[15:19] <michaelni> pierre-olivierro, a hack to get side data working is to call av_packet_merge_side_data() probably
[15:20] <durandal_1707> icoenc have some funny code
[15:21] <durandal_1707> libavformat/icoenc.c:48:62: warning: self-comparison always evaluates to false [-Wtautological-compare]
[15:22] <wm4> durandal_1707: why did you accept the jpeg colorspace hack? isn't that deprecated?
[15:22] <durandal_1707> wm4: i'm evil
[15:22] <wm4> hurr
[15:23] <durandal_1707> seriously, alternative does not work and nobody cares
[15:23] <wm4> what alternative are you thinking of
[15:23] <durandal_1707> the one which caused pix fmt to get deprecated at first place
[15:24] <durandal_1707> iirc setting color_range (lol)
[15:24] <wm4> it's as easy as passing through color levels
[15:25] <durandal_1707> it is more like color space, thats why is there yuv444 and rgb and not just some 888 format
[15:25] <nevcairiel> the problem is swscale, it only really works properly with the J pixfmts, trying to set it through other means fails
[15:26] <wm4> nevcairiel: I think that got fixed
[15:26] <nevcairiel> at least thats my experience
[15:26] <nevcairiel> maybe, i didnt re-try for a year or so =P
[15:26] Action: nevcairiel has his own yuv->rgb now
[15:26] <durandal_1707> wm4: really? swscale does care what is color_range at all
[15:26] <wm4> half a year ago, it worked, but using it with RGB yielded random results (this was fixed too)
[15:27] <wm4> so vf_colormatrix seems to be redundant too to vf_scale
[15:27] <wm4> (if vf_scale would handle colorspaces/ranges correctly)
[15:28] <durandal_1707> it is trivial to make colormatrix just call swscale (if swscale really can do that)
[15:29] <wm4> I think it can (though I'm not 100% sure)
[15:31] <durandal_1707> when i asked michaelni (swscale author) about it, he said it is incomplete
[15:31] <wm4> well, I think I did verify it to some degree
[15:32] <wm4> though I did only try hard with ranges (there's even a test program on some ticket), while I just visually confirmed color_space_
[15:33] <michaelni> rgb->yuv doesnt support all yuv variants but thats independant of how the yuv variant is specifid (color_* or pixfmt)
[15:35] <michaelni> also the first thing sws does with yuvj is to change the pixel format to the yuv variant and set the color_* stuff apropriately
[15:37] <durandal_1707> because there is no way to change color_* stuff via lavfi, there is no way to force same color_* stuff in blend filter
[15:57] <Granjow> Hi there! I use this code for seeking: http://codepad.org/AMyojmxV Problem is, works fine for the first 14 frames, but then I get this frame twice (so the frames returned consecutively are 13 14 14 15 16 etc.).
[15:57] <Granjow> How can this happen?
[16:01] <Granjow> Should seeking not be accurate?
[16:12] <wm4> Granjow: no, seeking usually snaps to key frames
[16:13] <wm4> Granjow: this is due to how video codecs work (you have to decode a number of frames to get a complete decoded picture of a non-keyframe)
[16:14] <wm4> Granjow: unless your video codec is intra-only of course (then every frame is a keyframe, and frame-exact seeking should be trivial)
[16:17] <Granjow> wm4: Not sure what it is:  Stream #0:0: Video: mjpeg (MJPG / 0x47504A4D), yuvj420p, 1280x1040, 10 tbr, 10 tbn, 10 tbc
[16:17] <wm4> Granjow: sounds like it is intra-only, what's your container?
[16:18] <Granjow> wm4: .avi? Or is the container format something else?
[16:20] <av500> the duplicated frame could be a simple rescale issue
[16:21] <Granjow> When I simply seek frames from 0 to 49 then I get more duplicates the further I seek: http://codepad.org/FVF25FUh And although the PTS/DTS jumps by 2, the actual frame does not
[16:21] <Granjow> av500: Rescale issue?
[16:21] <av500> int64_t seekTarget = av_rescale_q(frame, AV_TIME_BASE_Q, rv->pCodecContext->time_base);
[16:21] <av500> does this produce the exact same timestamps as when playing the file?
[16:22] <av500> ok, seems so with an 1/10 timebase
[16:22] <Granjow> av500: I'm not actually using seekTarget, sorry for the code still being there. I just work with the frame number directly since seekTarget is always 0.
[16:22] <av500> ah right
[16:23] <av500> what container?
[16:23] <Granjow> how can I find out? File extension is .avi
[16:23] <wm4> then it's probably avi
[16:24] <wm4> maybe av_seek_frame is limited by the precision of the avi index? I can only guess here
[16:24] <av500> the AVI index has every frame
[16:24] <av500> or should
[16:25] <av500> but I dont see AVSEEK_FLAG_FRAME support in AVI
[16:25] <Granjow> Not sure, but I just happened to try and find the aviindex utility
[16:25] <av500> oops
[16:25] <wm4> Granjow: if you need frame exact access, you could use ffms
[16:25] <wm4> Granjow: http://code.google.com/p/ffmpegsource/
[16:26] <Granjow> http://codepad.org/R6lAV7IF are the first lines
[16:27] <av500> Granjow: try to seek to a timestamp
[16:27] <av500> the one from the av_rescale
[16:27] <Granjow> wm4: sounds convenient. But afair there is a fix in ffmpeg which is not yet included in their version.
[16:27] <av500> and drop the frame flag
[16:28] <wm4> Granjow: "their version"? ffms uses ffmpeg proper as library
[16:28] <wm4> Granjow: it just does all the indexing stuff for you
[16:28] <wm4> Granjow: so depending on what you want to do, this might be a great time saver
[16:28] <Granjow> av500: How do I use av_rescale correctly? Since my seekTarget is constantly at 0
[16:28] <av500> Granjow: I dont know, see the source code
[16:30] <Granjow> wm4: Ah. Well, currently I have already written a wrapper for everything I need, except correct seeking, that is. Is it in development? I.e. is ffmpegsource alive?
[16:31] <TheFluff_> it needs updating for some new ffmpeg stuff but nobody has gotten around to it yet since all of the developers got busy with their fulltime jobs
[16:31] <wm4> Granjow: it's been used a long time and seems very much stable (I haven't used it myself, but it's used for avisynth and aegisub)
[16:31] <av500> AVI is pretty much frame number based already
[16:31] <av500> I dont think a wrapper can help much
[16:31] <TheFluff_> plork said he was going to look at it one of these eekends
[16:32] <TheFluff_> or well he actually did look at it already, it's just kinda buggy and not ready to be merged yet
[16:32] <wm4> av500: AFAIk the advantage is that ffms already contains all workarounds needed, and it'll work for any (or most) formats
[16:32] <JEEB> TheFluff_, I think his git master got merged into trunk
[16:33] <JEEB> so now ffmpegsource's trunk can be built with current ffmpeg, methinks
[16:33] <TheFluff_> oh
[16:33] <TheFluff_> yes
[16:33] <TheFluff_> he merged it yesterday
[16:34] <av500> wm4: I understand that
[16:35] <TheFluff> Granjow: ffmpeg and correct seeking do not get along well, that's why things like ffms and l-smash exist
[16:36] <TheFluff> I'd say that if you care about more than one format it's gonna be pretty annoying to roll your own seeking solution
[16:36] <Paranoialmaniac> ?
[16:36] <Granjow> TheFluff: 
[16:36] <TheFluff> Paranoialmaniac: sorry if I mis-alerted you
[16:37] <Paranoialmaniac> l-smash and l-smash works is different thing :P
[16:37] <TheFluff> right
[16:38] <Paranoialmaniac> well, l-smash works can handle intra-refresh and pre-roll using l-smash
[16:38] <Granjow> TheFluff: Yeah, actually more than 0 formats apparently. As far as I see I would have to try to guess the correct AVPacket.pos and then advance until I'm at the right position, or something like this o.O 
[16:40] <Granjow> I guess I'll do a quick test of ffmpeg source and switch to it if it works.
[16:40] <av500> Granjow: your AVI file is video only with all frames as key frames
[16:41] <av500> so seeking to a timestamps as frame# * timebase should work
[16:41] <av500> otherwise its a bug
[16:43] <Granjow> av500: Does not work, I removed the flag and get the same results.
[16:45] <av500> print the timestamps and frame numbers pls
[16:45] <wm4> I think I can say libavformat in general proved to be pretty unreliable for me
[16:45] <av500> also the resulting pts/dts
[16:45] <wm4> even mplayer's really crappy demuxers sometimes work better
[16:45] <av500> yeah, but seeking in AVI is pretty straightforward
[16:45] <av500> if that is broken it should be fixed
[16:46] <av500> instead of relying on ffms to fix it
[16:46] <wm4> also I have to say mhpeg in avi sounds pretty obscure
[16:46] <wm4> *mjpeg
[16:46] <Granjow> av500: Which fields are those?
[16:47] <Granjow> AVPacket.?
[16:47] <av500> pts
[16:47] <av500> dts
[16:47] <av500> wm4: that is not obscure at all
[16:47] <av500> digital cameras did that for a long time for "video recordings"
[16:48] <av500> some at least
[16:48] <av500> Canon_Ixus_750.avi
[16:49] <av500> Casio_Exilim.avi
[16:49] <av500> CanonSD800is.AVI
[16:51] <Granjow> av500: http://codepad.org/tgtxfPfE
[16:53] <durandal_1707> wm4: what is unreliable in lavf?
[16:53] <Granjow> Somehow it starts failing after the last frame I already read in in the first loop
[16:53] <Granjow> If I only read the first 5 frames and then start seeking, then it fails there already, now with 30 it fails at 31
[16:54] <durandal_1707> Granjow: what codec ?
[16:54] <Granjow> Here is the same but only reading 5 frames first http://codepad.org/zj5KWg20
[16:55] <Granjow> durandal_1707: Where? Used in my code or described by ffmpeg?
[16:55] <durandal_1707> the one you use with code
[16:56] <Granjow> durandal_1707: Not sure, I open it automatically: http://codepad.org/5ngEtkqb
[16:56] <durandal_1707> hmm, i don't see why seeking could not work, it is keyframe only stream
[16:57] <Granjow> ah, I'm actually printing it
[16:57] <Granjow> MJPEG (Motion JPEG)
[17:01] <wm4> durandal_1707: with some broken wmv files, I can't even seek backwards
[17:01] <wm4> durandal_1707: and incomplete uninterleaved avi files are unseekable
[17:01] <wm4> durandal_1707: even though all of these work with mplayer demuxers
[17:02] <wm4> durandal_1707: so yeah, there are plently of obscure cases left where mplayer internal demuxers work better than lavf
[17:02] <durandal_1707> open ticket
[17:03] <wm4> I did
[17:03] <Granjow> I have uploaded the avi file here: http://granjow.net/uploads/temp/seeking.avi (400 MB) for testing. 
[17:04] <wm4> durandal_1707: https://ffmpeg.org/trac/ffmpeg/ticket/1993
[17:04] <Granjow> Just in case it might help.
[17:04] <wm4> durandal_1707: "FFmpeg does not support non-interleaved avi files without index"
[17:05] <Granjow> Need to run for the train now -- thanks a lot for helping. Will check if ffmpegsource works and switch in case it does.
[20:26] <NovaSt0rM> is there a fastish reliable way to determine the number of bytes that would be decoded in an audio stream?
[20:26] <NovaSt0rM> using av_read_frame but skipping the actual decode part?
[20:29] Action: NovaSt0rM reads the topic
[22:28] <FFmpeg-github> 01[13FFmpeg01] 15none pushed 3 new commits to 06master: 02http://git.io/Qywsuw
[22:28] <FFmpeg-github> 13FFmpeg/06master 148097e5b 15Michael Niedermayer: yop: Fix return type...
[22:28] <FFmpeg-github> 13FFmpeg/06master 1467607e2 15Michael Niedermayer: xxan: make code independent of sizeof(AVFrame)...
[22:28] <FFmpeg-github> 13FFmpeg/06master 14a2f7314 15Michael Niedermayer: libpostproc: silence valgrind/fate warning about using uninitialized data...
[22:29] <gnafu> Well, that's new.
[22:30] <FFmpeg-github> 01[13FFmpeg01] 15michaelni pushed 1 new commit to 06master: 02http://git.io/i1LLDw
[22:30] <FFmpeg-github> 13FFmpeg/06master 14ea4c99d 15Michael Niedermayer: dshow_pin: dont return a value from a void function...
[22:31] <michaelni> i enabled the github bot again until cone re-appears
[22:31] <gnafu> :-)
[22:34] <durandal_1707> but this one gives delayed spam
[22:37] <michaelni> yes ... you can ask j-b or thresh about cone, i dunno why its not here ...
[22:37] <durandal_1707> it wasted too much bandwitch?
[23:26] <saste> llogan?
[23:41] <FFmpeg-github> 01[13FFmpeg01] 15michaelni pushed 1 new commit to 06master: 02http://git.io/XH1qOg
[23:41] <FFmpeg-github> 13FFmpeg/06master 144a595cf 15Michael Niedermayer: ffserver/ctime1: avoid using strcpy()...
[23:42] <j-b> michaelni: thresh will fix tomorrow, he said
[23:42] <michaelni> j-b, ok thx
[23:48] <saste> is mashiat sarker on IRC?
[23:49] <saste> what's usually his nickname?
[23:50] <ubitux> shahriman?
[23:51] <saste> ok
[00:00] --- Tue Mar 26 2013