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

[burek]

[00:00] <ubitux> Compn: i mean pushing to a loopback device
[00:05] <Compn> yeah, playing to a v4l so you can read it from a webcam
[00:08] <ubitux> Compn: don't get me wrong, i'm not talking about emulating a device
[00:08] <ubitux> just pushing video data to a v4l2 device.
[00:16] Action: llogan is unsurprised at response of mail bounce man
[00:26] <cone-610> ffmpeg.git 03Carl Eugen Hoyos 07master:1c0d8f2563cc: Add a work-around for msvc compilation until c99-to-c89 issue 7 is fixed.
[00:43] <cehoyos> ubitux: Does this happen regularly? http://fate.ffmpeg.org/report.cgi?time=20130403122950&slot=x86_64-archlinux-gcc-threads-8
[04:12] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:e10f5bd05cec: avformat: Add a mechanism to allow demuxers to detect byte based seeking.
[04:12] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:e278500181b8: oggdec: Support byte based seeking
[05:05] <Zeranoe> There seems to be an issue with FFmpeg's moov atom support in 32-bit builds for large files. I think the issue might be here: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;h=3c54ef3834bc5844261a404c445d92961d8f29da;hb=HEAD#l2611 in the mov.c file on line 2611
[05:05] <Zeranoe> FFmpeg errors that it cannot find the moov atom with large files on a 32-bit machine
[08:28] <ubitux> ./ffplay 'http://www.youtube.com/watch?v=buU8gPG2cHI'
[08:28] <ubitux> yepee~
[08:36] <wm4> ubitux: you're making ffplay your media player?
[08:36] <ubitux> yes
[08:36] <wm4> fucking lol
[08:36] <ubitux> :(
[08:36] <ubitux> the main problem being the muxed subtitles
[08:37] <ubitux> i also miss a little the osd
[08:37] <wm4> so, you know, there's this thing called media player
[08:37] <ubitux> the rest is finem mostly so far
[08:37] <wm4> and there are dozens of them around
[08:37] <wm4> and they all have hard working people trying to improve them
[08:38] <ubitux> (honestly i'm using mpv most of the time you know :p)
[08:38] <wm4> so why bloat a sample program with that stuff?
[08:38] <ubitux> i'm not bloating ffplay
[08:38] <ubitux> i've added a libquvi demuxer
[08:38] <wm4> then you're bloating libavformat
[08:38] <ubitux> just don't manually --enable-libquvi
[08:39] <wm4> oh well I guess I shouldn't be surprised anymore
[08:39] <ubitux> it's not 150 lines of a little demuxer that are going to hurt
[08:39] <ubitux> it's handy :)
[08:40] <ubitux> you can even ffprobe youtube now
[08:40] <ubitux> isn't that awesome?
[08:45] <wm4> if ffmpeg strives to become some sort of multimedia framework, you should try working on making the API a bit higher level
[08:46] <av500> libavplay
[08:46] <av500> and ffplay/avplay would use that
[08:47] <wm4> it would make sense... it could return decoded data, and all the frontend would have to do is displaying the output and synchronizing it
[08:48] <av500> I would let it do the sync too
[08:48] <av500> it could have pluggable "sinks"
[08:48] <av500> use an existing one or write your own to the API
[08:49] <wm4> depends what synchronizing actually means...
[08:49] <wm4> but "sinks" sounds like overcomplex gstreamer/dshow stuff again
[08:49] <av500> well, you have to render somewhere
[08:50] <wm4> that's highly application specific... ffmpeg.c could be using it too
[08:50] <av500> I'd see libavplay as load(url), play(), seek(), stop()
[08:51] <av500> so not on a per frame level
[08:51] <wm4> that would be even higher level, not sure if I'd like that
[08:51] <av500> well, it's the "play" in the name :)
[08:51] <wm4> but still much better than torturing everyone with ffmpeg's low level API
[08:52] <wm4> e.g. think about people who just want raw data out of a media file
[08:52] <wm4> which is probably the most common case for libav* users
[08:52] <av500> av_read_frame() :)
[08:53] <wm4> ffplay.c would be much shorter if it were that simple
[08:53] <av500> for a start I would be happy if ffplay even compiles without SDL
[08:53] <nevcairiel> and output stuff how then? :p
[08:53] <av500> and renders frames to a "dummy" in this case
[08:54] <ubitux> av500: what would be the point?
[08:54] <wm4> also I dread what will happen if they really start porting mplayer's libvo to ffplay (because one gsoc sounded like this)
[08:54] <ubitux> ./ffmpeg -re -i ... -f null -
[08:54] <av500> ubitux: yes, that would work too
[08:55] <av500> but not the same
[08:55] <ubitux> what's the difference?
[08:55] <ubitux> seek maybe?
[08:56] Action: ubitux wonders what's the use case
[08:56] <wm4> also, if you have such a higher level interface, maybe you could get rid of stuff like the image or concat demuxers
[08:56] <wm4> these are really just hacks to retrofit higher level use cases to a lower level API
[08:58] <av500> wm4: yes, in the end it might come down to another libvo and libao
[08:59] <av500> that plugs into a libavplay
[09:00] <wm4> and then history will repeat
[09:03] <av500> as it always does :)
[09:03] <av500> or I might look at libvlc
[09:03] <av500> using that as player frontend to lavf/lavc
[09:03] <wm4> yeah, libvlc is the kind of thing that is much more useful than raw libav*
[09:04] <wm4> for developers of frontends or such
[09:04] <wm4> as a bonus it compensates for areas where ffmpeg sucks (like .ts demuxer for broadcast uses)
[09:07] <av500> one could fix the ts demuxer
[09:07] <wm4> patches welcome?
[10:05] <ubitux> saste: the ffprobe.texi "see also" section is a bit broken
[10:05] <ubitux> in addition to the ffplay,ffmpeg thing, it seems to refer to ffprobe but not ffmpeg
[10:06] <ubitux> i believe you want to ref ffprobe-all, and all the other tools !ffprobe
[10:06] <ubitux> (yes that's not a problem in your current patch)
[10:14] <cone-236> ffmpeg.git 03Stefano Sabatini 07master:d344b99954eb: doc/ffprobe: fix references in See Also section
[10:17] <ubitux> :)
[10:20] <ubitux> saste: btw, since the shorthand are going to be broken/useless soon, i was wondering if we couldn't simplify AVOption aliases by simply having names "foobar,f"
[10:21] <saste> ubitux, so are we going to break compatibility
[10:21] <ubitux> ?
[10:21] <ubitux> i think we can avoid it
[10:22] <saste> ubitux, AVOption is not making assumption about the characters in the key
[10:22] <saste> no i don't know what i say
[10:22] <saste> because i don't know what you really want
[10:22] <ubitux> do you know any option with a comma in it?
[10:23] <saste> ubitux, no
[10:23] <ubitux> the idea is just this:
[10:23] <ubitux> -    { "luma_radius",    "set luma radius",    OFFSET(luma.radius),    AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },
[10:23] <ubitux> -    { "lr"         ,    "set luma radius",    OFFSET(luma.radius),    AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },
[10:23] <ubitux> +    { "luma_radius,lr", "set luma radius",    OFFSET(luma.radius),    AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },
[10:23] <ubitux> and so the "automatic shorthand" from anton could work nicely
[10:24] <ubitux> without for us the need to move the aliases at the end
[10:24] <ubitux> where it will make no sense
[10:37] <saste> ubitux, no objections from me
[10:38] <saste> although technically it is a compatibility break
[10:38] <saste> since opt.h users may rely on options having ",", even if this is very unlikely
[10:38] <saste> also in this case we should document the assumption
[10:38] <ubitux> ok
[10:39] <saste> ubitux, the makefile factorization trick doesn't seem to work
[10:39] <ubitux> ok :(
[10:39] <saste> i'm posting an updated patch, and will push the patchset in a few days if i read no more comments
[11:03] <ubitux> is the migration to the new fate done?
[11:55] <wm4> michaelni: is there any reason why there's is swr_set_channel_mapping() for changing input channel order, but no function to change output channel order?
[12:03] <ubitux> michaelni: 
[12:03] <ubitux> 12:01:39 < CharlieB> i can tell you that you don't need a specific user agent for google tl
[12:03] <ubitux> 12:02:14 < CharlieB> it needs *some* useragent for google tl
[12:03] <ubitux> 12:02:23 < CharlieB> it only sets it if none is set so far
[12:03] <ubitux> 12:02:41 < CharlieB> hence "just provide a default"
[12:03] <ubitux> also, it might be more relevant to have a -browser-user-agent AVOption to just emulates a browser
[12:04] <ubitux> instead of such hardcode
[12:05] <michaelni> ubitux, there is a default user agent, which is LIBAVFORMAT_IDENT
[12:05] <ubitux> is it really sent?
[12:06] <wm4> yes
[12:08] <michaelni> btw the ticket also contains an example where wget with "random" user agent fails
[12:12] <ubitux> michaelni: i'll send a better patch for this soon
[12:18] <ubitux> michaelni: patch sent
[12:21] <saste> ubitux: so now libavformat/http is *always* lying
[12:21] <wm4> michaelni: also, swr_set_channel_mapping() stores the user pointer in the SwrContext
[12:21] <ubitux> saste: not really
[12:21] <ubitux> saste: it's announcing mozilla but lavf is still present
[12:22] <ubitux> saste: it's just a more compatible user agent
[12:22] <wm4> michaelni: and it's not even documented that the channel_map pointer will be referenced later after the call has returned
[12:23] <saste> what's the point of using "mozilla" by default? It's not like libavformat = mozilla
[12:23] <saste> why to lie?
[12:23] <saste> also what's problem is really resolving?
[12:23] <saste> user-agent filters change day by day, so what's good today for a website will change tomorrow
[12:23] <ubitux> saste: a lot of website are checking for mozilla and other compatible browsers
[12:24] <saste> hardcoding this in a library really doesn't help much
[12:24] <ubitux> saste: even IE is going to hardcode Mozilla in its user agent you know
[12:24] <saste> yes and why all this insanity? this way user-agent is totally void of meaning
[12:24] <ubitux> and IE, chromium, mozilla etc are basically sharing a lot of crap like this because of this
[12:24] <ubitux> saste: there is still "lavf" and its version
[12:24] <michaelni> wm4, ubitux added the channel maping stuff, best you ask him about the why this why that 
[12:24] <ubitux> it's like compatible brands
[12:25] <michaelni> i can fix the docs of course if thats what is wanted
[12:25] <wm4> libavresample doesn't do this, so maybe it should be fixed properly
[12:25] <ubitux> wm4: it's an old code i don't remember :p
[12:26] <wm4> int swr_set_channel_mapping(struct SwrContext *s, const int *channel_map){
[12:26] <wm4>     if(!s || s->in_convert) // s needs to be allocated but not initialized
[12:26] <wm4>         return AVERROR(EINVAL);
[12:26] <wm4>     s->channel_map = channel_map;
[12:26] <wm4>     return 0;
[12:26] <wm4> }
[12:26] <wm4> reminder ^
[12:26] <saste> ubitux, i'm going to ask google guys about the streamer issue
[12:27] <wm4> and again, is there no way to reorder output? so you have to create a second SwrContext (with same input and output format config, and setting an inverse channel map) for reordering?
[12:28] <michaelni> wm4 ill put make swr_set_channel_mapping alloc data on my todo but my todo is long so if you want to quick, send a patch
[12:28] <michaelni> s/to quick/it quick/
[12:29] <wm4> well, I don't really care, but it's a pitfall for anyone trying to use the API
[12:29] <ubitux> wm4: i don't understand why you would want input and output mapping
[12:29] <michaelni> wm4, i fully agree 
[12:29] <wm4> ubitux: why not?
[12:30] <ubitux> i'm just wondering about the use case
[12:30] <ubitux> saste: google is certainly not the only website doing such exceptions
[12:31] <wm4> ubitux: consider remixing 3 channel input to 5 channels, and then outputting it to ALSA
[12:32] <wm4> input channel order/layout is just ffmpeg, while the output order/layout might be something completely different
[12:34] <michaelni> wm4 i think you can use swr_set_matrix() to get any output mapping, a simpler API should be added of course
[12:34] <Kovensky> <@saste> yes and why all this insanity? <-- this all started back when Netscape was new
[12:35] <Kovensky> Mozilla was Netscape's UA string (because it was the browser's internal codename)
[12:35] <Kovensky> then sites started checking for whether the browser was Mozilla to enable newer features that Mosaic didn't support
[12:35] <Kovensky> everything that came after Netscape declared it was Mozilla for compatibility
[12:46] <cone-236> ffmpeg.git 03Luca Barbato 07master:19f251a2882a: clang: use -fsantize=address and -fsanitize=thread
[12:46] <cone-236> ffmpeg.git 03Dale Curtis 07master:fc43c19a567a: matroska: Update the available size after lace parsing
[12:46] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:57b191b82ab2: Merge commit 'fc43c19a567aa945398dccb491d972c11ec2a065'
[12:54] <cone-236> ffmpeg.git 03Luca Barbato 07master:8a96df7b70be: matroska: fix a corner case in ebml-lace parsing
[12:54] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:534b2921028a: Merge commit '8a96df7b70be509dae9ceec82d2c10a20361356d'
[13:06] <cone-236> ffmpeg.git 03Luca Barbato 07master:25a80a931a38: matroska: pass the lace size to the matroska_parse_rm_audio
[13:06] <cone-236> ffmpeg.git 03Peter Meerwald 07master:dfcbe8cbd78b: doc: Fix best_nb_channells typo
[13:06] <cone-236> ffmpeg.git 03Anton Khirnov 07master:bcc94328980e: opt: check the return values of av_get_token for ENOMEM.
[13:06] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:e7389ed5d0bd: Merge commit 'bcc94328980e6c56546792ab08b0756abdce310b'
[13:25] <cone-236> ffmpeg.git 03Anton Khirnov 07master:6d0546bbaf16: avfiltergraph: set deprecated filter_count.
[13:25] <cone-236> ffmpeg.git 03Anton Khirnov 07master:dbb1425811a6: lavf: make sure stream probe data gets freed.
[13:26] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:ab2989378fc5: Merge commit 'dbb1425811a672eddf4acf0513237cdf20f83756'
[13:47] <cone-236> ffmpeg.git 03Anton Khirnov 07master:3623589edc7b: dfa: check for invalid access in decode_wdlt().
[13:47] <cone-236> ffmpeg.git 03Anton Khirnov 07master:8d617b11cfc8: id3v2: pad the APIC packets as required by lavc.
[13:47] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:cdafcf838cc7: Merge commit '8d617b11cfc87b2c6056fee029ac5bc760af874a'
[13:59] <Bor0> why is it that av_buffersink_get_frame_flags() for some videos it returns frame->pts not divided by 1000, and for some videos it returns divided by 1000.  I want to get the current frame
[14:00] <kierank> depends on the timebase
[14:03] <Bor0> how can I check that?
[14:03] <durandal_1707> ubitux: ping
[14:03] <ubitux> durandal_1707: pong
[14:03] <durandal_1707> ubitux: did you broke blend filter?
[14:04] <ubitux> did i?
[14:14] <durandal_1707> what happened with smptebars?
[14:14] <durandal_1707> i get wrong colors and weird stripes
[14:15] <durandal_1707> looks like swscale or something does not like -O0
[14:16] <ubitux> i get green stripes indeed here too
[14:16] <durandal_1707> huh
[14:16] <ubitux> http://ubitux.fr/pub/pics/_smptebars.png
[14:16] <durandal_1707> needs to find regression and add fate coverage asap
[14:16] <ubitux> this is what i have here
[14:17] <ubitux> durandal_1707: so something broke in blend filter you say?
[14:17] <durandal_1707> i tried to add more blend filter examples, so that why i thought it was blend filter fault ...
[14:17] <ubitux> heh ok
[14:17] <durandal_1707> but it is smptebars fault
[14:18] <durandal_1707> smptebars and colors are only filters that just dupe frames
[14:18] <durandal_1707> so something in this case got funky
[14:18] <ubitux> maybe a regression in ff draw api
[14:19] <ubitux> check be0a67bd
[14:20] <durandal_1707> smptebars dont use blend stuff
[14:21] <ubitux> ok
[14:21] <ubitux> maybe the get buffer init then
[14:21] <ubitux> the filter might have been assuming zero-filling
[14:23] <durandal_1707> does not explain weird colors
[14:24] <ubitux> bugs are like mushrooms
[14:24] <ubitux> you find one and there are tons around
[14:25] <wm4> nice one
[14:26] <wm4> MPlayer code is less like mushrooms, and more like... mold everywhere
[14:26] <ubitux> that can be cute
[14:29] <ubitux> wm4: ffplay -f lavfi life=s=300x200:mold=10:r=60:ratio=0.1:death_color=#32C832:life_color=#00ff00,boxblur
[14:29] <ubitux> isn't this cute?
[14:29] <ubitux> mold ftw
[14:30] <wm4> even more useless than the stuff I do in mpv
[14:30] <ubitux> don't be jealous
[14:30] <durandal_1707> ffplay become recently more buggy
[14:31] <ubitux> durandal_1707: something broke?
[14:31] <cone-236> ffmpeg.git 03Anton Khirnov 07master:b88f902125ee: bmv: check for len being valid in bmv_decode_frame().
[14:31] <cone-236> ffmpeg.git 03Anton Khirnov 07master:d1016dccdcb1: xmv: check audio track parameters validity.
[14:31] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:208be6b54a91: Merge commit 'd1016dccdcb10486245e5d7c186cc31af54b2a9c'
[14:32] <michaelni> ffplay needs regression/fate tests
[14:33] <nevcairiel> hard to fate test a visual player
[14:33] <michaelni> replace stuff like time() by something deterministic, replace output by "fwrite"
[14:34] <michaelni> wont catch all regerssions of course but i think it should help
[14:34] <durandal_1707> ubitux: useless frame droping
[14:35] <durandal_1707> ffplay sucks, use mpv
[14:35] <durandal_1707> mpv avdevice://lavfi:life=s=800x600:mold=10:r=60:ratio=0.1:death_color=#32C832:life_color=#00ff00,boxblur
[14:36] <ubitux> durandal_1707: i noticed the frame dropping thing
[14:36] <ubitux> i told michael about it when i spotted it with mandelbrot
[14:36] <durandal_1707> and this sdl thing that crashes here when i press f
[14:36] <ubitux> no pb with fullscreen here
[14:36] <cone-236> ffmpeg.git 03Anton Khirnov 07master:f8080bd13b5f: xmv: do not leak memory in the error paths in xmv_read_header()
[14:36] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:7ad359b3949c: Merge remote-tracking branch 'qatar/master'
[14:37] <michaelni> ubitux, did you report it to marton ?
[14:37] <ubitux> i should have
[14:37] <ubitux> but i was too lazy to bisect :(
[14:38] <michaelni> he wont fix if he doesnt know about it
[14:38] <ubitux> yeah i know...
[14:38] <ubitux> i was a bit busy and didn't took the time to bisect
[14:42] <ubitux> durandal_1707: btw, still don't motivated to port eq2?
[14:42] <ubitux> :(
[14:42] <ubitux> s/don't/not/
[14:42] <durandal_1707> ubitux: isn't it just lut?
[14:43] <durandal_1707> ubitux: i currenly only motivated to fix smptebars
[14:43] <ubitux> maybe
[14:47] <durandal_1707> looks like it is because of rounding, and 1 pixel left unchanged
[14:49] <durandal_1707> but this was not happening before
[14:53] <durandal_1707> i think using drawutils was just bad idea from start, because drawutils is hack
[14:53] <durandal_1707> and does not support yuv correctly
[14:54] <wm4> needs libavcomposite
[14:54] <durandal_1707> what that does?
[14:55] <durandal_1707> ubitux: looks like it is caused by subsampling
[14:55] <wm4> drawing stuff on top of other stuff
[15:02] <durandal_1707> perhaps i could align to 4
[15:09] <ungurean_> i was looking over the tasks for Google SoC and apng got my attention. even though it`s not sure ffmpeg will get into SoC i will really want to have some contribution to the apng part. i have some questions related decoding. the start of a apng file is exatly like a png but has 3 additional chunk types...so for good format matching the acTL chunk must be there, right ?
[15:10] <durandal_1707> somewhere is spec is described when such chunks should appear
[15:10] <durandal_1707> so just follow spec
[15:22] <ubitux> srsly why the fuck is ffplay inserting scaler all around for no reason
[15:24] <ubitux> foobar filter having yuv420p and rgb24 pix formats; -vf format=rgb24,foobar works as expected with ffmpeg
[15:24] <ubitux> but with ffplay it adds a fucking rescaler between the two
[15:27] <wm4> huh
[15:27] <wm4> shouldn't this be up to libavfilter
[15:27] <ubitux> that's what i thought
[15:27] <wm4> also, ffplay can do 420p output only, while ffmpeg can do more?
[15:27] <ubitux> but since it works with ffmpeg but not ffplay, i'm guessing there is some misconfiguration or something somewhere
[15:27] <ubitux> wm4: right
[15:27] <ubitux> but there is no reason for adding a convert filter here
[15:28] <ubitux> it can be done post foobar
[15:29] <wm4> also, how can you see what filters are inserted by libavfilter?
[15:29] <ubitux> -v verbose
[15:30] <ubitux> [auto-inserted scaler 0 @ 0x7fa75c3a47a0] w:640 h:352 fmt:yuv420p sar:1/1 -> w:640 h:352 fmt:rgb24 sar:1/1 flags:0x4
[15:30] <ubitux> [auto-inserted scaler 1 @ 0x7fa75c3a4960] w:640 h:352 fmt:rgb24 sar:1/1 -> w:640 h:352 fmt:yuv420p sar:1/1 flags:0x4
[15:30] <ubitux> brilliant.
[15:31] <nevcairiel> rgb only filter in the middle? :d
[15:31] <ubitux> -vf format=rgb24,foobar
[15:31] <ubitux> foobar takes rgb24 and yuv420p
[15:31] <ubitux> and i wanted to force rgb24 input
[15:31] <ubitux> except i can't with ffplay
[15:32] <nevcairiel> i think it needs yuv420 for display, sdl restrictions, so may it do this after the foobar?
[15:32] <wm4> magic sws flags maybe?
[15:33] <ubitux> nevcairiel: the yuv420p convert is inserted between format=rgb24 and foobar
[15:33] <ubitux> not after foobar
[15:33] <nevcairiel> hmk, just wondering
[15:34] <ubitux> so what happens with ffplay is: auto-scale-to-rgb24 -> format=rgb24 -> auto-scale-to-yuv420p -> foobar
[15:34] <nevcairiel> maybe ffplay tells lavfi that it only accepts yuv420 on the output, and for some reason lavfi decides to scale one earlier instead of one later?
[15:34] <wm4> maybe lavfi thinks converting before the filter is somehow better than after?
[15:34] <nevcairiel> ffplay doesnt have  its own filtergraph builder, does it?
[15:34] <ubitux> why with ffplay only?
[15:34] <ubitux> ffmpeg output is also yuv420p
[15:37] <durandal_1707> ffplay simply should not instert anything in middle
[15:42] <wm4> format negotiation is surprisingly complex
[15:42] <wm4> it's not really clear that it's nonsense to convert right after vf_format
[15:42] <wm4> unless vf_format is specially handled
[15:44] <ubitux> since format=rgb24 output is rgb24 and foobar takes rgb24 input, i see no reason whatsoever for a scale filter to be inserted here
[15:44] <wm4> you could say the same for foobar and the buffersink filters
[15:46] <durandal_1707> lavfi should in theory always pick better pix fmt when filtering between different pix fmts
[15:46] <ubitux> if the buffersink requests a yuv420p and the output of foobar is rgb24, then it just needs insert a scaler
[15:46] <durandal_1707> ffplay random injection is pointless
[15:46] <durandal_1707> iirc it also happens with audio
[15:47] <ubitux> btw, shouldn't we remove the libav guys from ffmpeg consulting page?
[15:47] <durandal_1707> no, they will consult instead of rewritting api
[15:48] <durandal_1707> or consult how to switch to new api 
[15:49] <ubitux> what i'm afraid of is a speech such as "ffmpeg is deprecated/replaced with libav" from someone who is linked on the ffmpeg.org
[15:51] <durandal_1707> then remove them
[15:53] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:740ebe468c05: dfa: remove redundant check
[15:53] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:14de77d67714: matroskadec: fix return code for too long xiph laces
[15:53] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:115c3bc41f24: matroskadec: Check for overflows in xiph lace decoding
[15:53] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:3b93bea9e3ca: matroskadec: Check EBML lace sizes.
[16:24] <ubitux> *dstp = f * (*srcp - 127) + 127; // am i doing something incorrect/stupid?
[16:24] <ubitux> (trying to scale chroma brightness)
[16:25] <ubitux> (uin8_t *dstp,*srcp)
[16:25] <ubitux> it seems to work, but i wonder if i'm not doing something overkill
[16:26] <ubitux> f in [0;1] (float)
[16:26] <durandal_1707> it's slow to go from float to int all the time
[16:26] <iive> chroma brightness?
[16:27] <nevcairiel> also called luma
[16:27] <nevcairiel> :P
[16:27] <durandal_1707> he doing equalizer thing probably
[16:27] <nevcairiel> but he means intensity
[16:27] <ubitux> that's for Cb Cr, and i'm adjusting the brightness
[16:27] <durandal_1707> doing via lut is faster 
[16:28] <durandal_1707> and eq2 is using big tables 256*256 for some reason
[16:28] <ubitux> yes i'll do a lut later
[16:28] <iive> ubitux: try without touching the chroma
[16:28] <nevcairiel> by definition, the brightness in a YCbCr image is in the Y, not the CbCr
[16:29] <ubitux> iive: it doesn't do what i want
[16:29] <iive> you want to change saturation too?
[16:29] <ubitux> iive: if i only play with the luma plane i never reach black
[16:29] <ubitux> just, this code works
[16:29] <ubitux> or at least it seems
[16:30] <ubitux> but it just looks somehow incorrect/overkill/stupid to me for some reason
[16:31] <durandal_1707> why? (it can be only slower if useful)
[16:32] <ubitux> maybe because i'm pre/post adjusting the source/result, and i'm wondering if i couldn't just do it at the f level
[16:33] <ubitux> i guess i'm just getting tired, 'will brainstorm
[16:33] <ubitux> i'm also surprised not to see such code in the existing code
[16:33] <ubitux> that's one of the reason i'm wondering :p
[16:33] <durandal_1707> what existing code?
[16:33] <ubitux> random filters
[16:34] <durandal_1707> most of them are from mplayer (which explains everything)
[16:34] <wm4> xD
[16:35] <wm4> so what will happen to vf_pullup etc?
[16:35] <nevcairiel> be gone
[16:35] <wm4> as in rm -f ?
[16:35] <ubitux> pullup might be useful for realtime
[16:35] <ubitux> fieldmatch/decimate is likely slower
[16:36] <nevcairiel> tivtc is so slow?
[16:36] <ubitux> well, it's fine here
[16:36] <ubitux> but i have a relatively fast machine
[16:36] <cone-236> ffmpeg.git 03Paul B Mahol 07master:6a08ccd61da0: lavfi/smptebars: fix output for subsampled yuv
[16:37] <nevcairiel> how much info does it need from the user to work? does it have a "auto" mode that just works in many cases? :d
[16:37] <ubitux> currently the default mode doesn't really seem to work as expected
[16:37] <ubitux> but i'm lazily waiting for Myrsloik to fix it
[16:38] <ubitux> also, it needs some little configuration; default might not work in various cases
[16:38] <ubitux> playing with the parity might be needed, assuming the frames have bad flags
[16:38] <nevcairiel> mhm per file settings are annoying for playback integration
[16:38] <ubitux> it's not meant to be used for playback anyway
[16:39] <wm4> back to yadif!
[16:39] <nevcairiel> doesnt do the same thing :P
[16:39] <wm4> nevcairiel: couldn't you just use avisynth?
[16:39] <ubitux> it can fallback on yadif too
[16:39] <nevcairiel> avisynth API is horrible
[16:39] <ubitux> nevcairiel: also, typically decimate needs to buffer 5 frames
[16:39] <ubitux> which adds to the slowdown
[16:40] <nevcairiel> i'm not worried about live sources or anything, so a bit of delay is fine
[16:40] <kurosu> ubitux / michaelni: so, about that rebasing my patches from libav to ffmpeg, what's the less painful way using git, but for someone with some incompatibilities with git like me ?
[16:41] <Compn> kurosu : were they applied in libav ?
[16:41] <kurosu> https://github.com/kurosu/libav <- the git tree
[16:41] <kurosu> Compn, they will probably though it's around the 3rd ping
[16:42] <Compn> kurosu : well if its already in git, michael can merge from there
[16:42] <ubitux> kurosu: git remote add ffmpeg git://...
[16:42] <Compn> no need to submit anything except the git repo url ...
[16:42] <Compn> assuming your changes are split up and dont have random/unrelated
[16:42] <ubitux> then rebase your branch onto a ffmpeg/master checkout
[16:43] <ubitux> and git send-email ffmpeg/master from your branch... i guess :)
[16:43] <kurosu> well it's a libav repo, and he expressed a preference of having them rebased so that the patches are actually tested under ffmpeg
[16:43] <Compn> oh :)
[16:43] <durandal_1707> ubitux: colors for smptebar are really wrong, yellow is orange and so on...
[16:43] <Compn> then ignore me :)
[16:43] <ubitux> durandal_1707: wouldn't that be related to a yuvj thing?
[16:43] <ubitux> like a broken range of colors
[16:44] <kurosu> there are also some incompatibilities because we improved things and I didn't bother submitting the updated stuff to libav
[16:44] <durandal_1707> i cant/dunno force input format
[16:45] <kurosu> ubitux: either by incompatibility, lazyness, incompetence or limited intellect, I cannot translate "then rebase your branch onto a ffmpeg/master checkout" into command lines
[16:45] <ubitux> kurosu: did you add a remote for ffmpeg?
[16:45] <kurosu> I'd probably want to keep my libav repo, and maybe "merge" into a ffmpeg repo instead
[16:45] <kurosu> not yet
[16:46] <ubitux> git remote add ffmpeg git://source.ffmpeg.org/ffmpeg.git 
[16:46] <ubitux> then git fetch ffmpeg
[16:46] <kurosu> should it be the official ffmpeg one or a copy I make for myself... oh ok
[16:46] <ubitux> in git branch -a you should see the remote and branches
[16:46] <ubitux> when you're here, ask again :p
[16:47] <kurosu> yeah, some MBs to fetch
[16:47] <ubitux> yup
[16:48] <durandal_1707> kurosu: uh, so why your changes are not in libav?
[16:48] <ubitux> durandal_1707: oh dear, don't be sarcastic
[16:48] <kurosu> takes forever, and I only spend a couple weeks on it every 3-4 month
[16:48] <kurosu> so any delay on the commiter side decuples my own delays
[16:49] <ubitux> OT: http://ubitux.fr/pub/pics/_vignette-halo.png  the white halo in the center is ugly, right?
[16:49] <kurosu> some of the changes I have up on that repo are maybe a year old because of that
[16:50] <kurosu> I would have preferred to send patches to both projects, but sometimes I can't take that much time
[16:50] <durandal_1707> kurosu: you replaced memcpy with AV_COPY128, the benchmark results before/after are missing
[16:50] <kurosu> this is a trivial change, and libc dependent
[16:50] <kurosu> not sure windows one matter
[16:51] <kurosu> but it is a change obvious in itself
[16:51] <kurosu> *by
[16:52] <durandal_1707> ubitux: bug or?
[16:53] <ubitux> durandal_1707: not really, or at least i don't think so
[16:53] <ubitux> durandal_1707: the idea is that it starts going to dark where you see the brightness
[16:53] <ubitux> so the center of the ellipse drown by this is untouched
[16:53] <ubitux> unfortunately the eye see notices the change
[16:53] <ubitux> and enlight it :p
[16:54] <ubitux> i don't really know how to solve that
[16:54] <kurosu> ubitux, done
[16:55] <ubitux> kurosu: ok, this is blind testing for me so... well, go in your dev branch, git checkout mydevbranch-rebased-on-ffmpeg
[16:56] <durandal_1707> ubitux: i don't think this is eye/brain thing
[16:56] <ubitux> kurosu: ah and, git checkout -b ffmpeg-master ffmpeg/master
[16:57] <ubitux> then go back to your mydevbranch-rebased-on-ffmpeg branch (git checkout mydevbranch-rebased-on-ffmpeg) and run git rebase ffmpeg-master
[16:57] <ubitux> fix your conflicts, git rebase --continue, iterate, etc
[16:57] <ubitux> durandal_1707: really?
[16:57] <ubitux> durandal_1707: i only see it in bright area
[16:58] <kurosu> in the list of branches, I have my local ones, the github ones, the origin ones (libav), the ffmpeg ones
[16:59] <kurosu> so what would that mydevbranch-rebased-on-ffmpeg be? I don't see any branches except the local ones and the github ones
[16:59] <kurosu> (that have code I want to rebase)
[16:59] <ubitux> durandal_1707: ubitux/github/vignette if you want to try
[17:00] <ubitux> kurosu: a copy of the branch of your work for libav
[17:00] <ubitux> but a copy which you'll rebase on ffmpeg
[17:00] <kurosu> oh ok
[17:00] <ubitux> without affecting the one rebased on libav
[17:01] <ubitux> git checkout mydevbranch-rebased-on-ffmpeg  this is to be run from your dev branch
[17:01] <ubitux> erm
[17:01] <kurosu> ok
[17:01] <ubitux> git checkout -b mydevbranch-rebased-on-ffmpeg
[17:01] <ubitux> to create it
[17:01] <ubitux> (from that particular work branch)
[17:01] Action: ubitux hopes he's clear enough
[17:01] <kurosu> Switched to a new branch 'aacsbr-ffmpeg'
[17:02] <kurosu> when should "git checkout -b ffmpeg-master ffmpeg/master" be run ?
[17:02] <durandal_1707> ubitux: what function you use to get brightness factor?
[17:03] <ubitux> see in my branch, get_brightness_factor() function
[17:03] <ubitux> kurosu: whenever
[17:04] <ubitux> i'm not even sure it's necessary btw
[17:04] <ubitux> you might be able to directly rebase on remotes/ffmpeg/master instead of ffmpeg-master
[17:05] <nevcairiel> you can
[17:05] <nevcairiel> even just ffmpeg/master will work, no need for remotes usually
[17:07] <kurosu> ok, no conflict, which sounds strange, as michael had some months ago
[17:07] <kurosu> how do I make sure the current branch is actually based on ffmpeg (I did ran git rebase ffmpeg-master)
[17:08] <durandal_1707> there is no avconv.c
[17:08] <ubitux> with git log --format=one, what is the first commit not from you?
[17:09] <kurosu> lavfi/smptebars: fix output for subsamp
[17:09] <kurosu> 6a08ccd61da040955ed24c0eb3d24ab4e860852a lavfi/smptebars: fix output for subsamp
[17:09] <durandal_1707> congratulations
[17:10] <kurosu> ok, then I need to config/make 
[17:10] <kurosu> and run fate to validate it works
[17:11] <kurosu> no, if I commit in one branch (ffmeg or libav based) and I want to merge the changes in the branch for the other project, how would I do that ?
[17:11] <kurosu> *now
[17:13] <kurosu> running configure under windows/mingw takes forever
[17:15] <nevcairiel> if you think thats forever, then run it with windows/msvc
[17:17] <kurosu> ah right now you can use msvc, though I wonder how practical it is for asm
[17:17] <nevcairiel> probably no difference, yasm is the assembler in both cases
[17:24] <kurosu> not going smoothly, after running configure with --disable-ffprobe --disable-ffserver --disable-symver, I get things like:
[17:24] <kurosu> CC      libavfilter/split.o
[17:24] <kurosu> /bin/sh: @printf: command not found
[17:25] <ubitux> oO
[17:25] <ubitux> oh, windows.
[17:25] <kurosu> I suspect this is the culprit: 104:    @-printf '\nWARNING: $(?F) newer than config.h, rerun configure\n\n'
[17:26] <kurosu> make-3.81.3 being used
[17:26] <ubitux> afaik we are using printf for ages
[17:26] <kurosu> i have printf
[17:27] <kurosu> it seems to not understand @-printf
[17:27] <kurosu> actually not
[17:30] <kurosu> ok, it doesn't understand the @ in front of commands in lines 15-20
[17:32] <cone-236> ffmpeg.git 03Paul B Mahol 07master:b1dea2c0d894: lavfi/blend: add N variable
[17:37] <durandal_1707> ubitux: that vignette effect could be done with blend filter when one filter is just static source....
[17:37] <durandal_1707> than you would just use dodge/burn
[17:38] <ubitux> yes, i can do it with geq as well
[17:38] <ubitux> :)
[17:38] <durandal_1707> ok, so your filter must be really fast
[17:39] <wm4> have you considered adding a lua evaluation filter?
[17:39] <wm4> luajit is insanely fast and can almost reach C speed
[17:40] <wm4> it's not secure, though
[17:40] <wm4> (which is why my mplayer fork doesn't have it in master, I guess)
[17:41] <durandal_1707> why jit?
[17:42] <wm4> because the jit compiles lua expressions to a few machine instructions
[17:42] <wm4> making it insanely fast
[17:44] <wm4> to make this clear: Lua and LuaJIT are two different implementations of Lua
[17:47] <durandal_1707> wm4: are you serious?
[17:48] <wm4> durandal_1707: yes, see vf_lua branch in mpv (but it's ooold)
[17:48] <durandal_1707> why not safe?
[17:49] <wm4> because luajit scripts (as long as they're allowed access to FFI) can do anything C can do
[17:49] <kurosu> ubitux, so how should I go with that issue of make not understanding @$(something) and line 15-20 of config.mak / Makefile ?
[17:49] <kurosu> I can fix it by removing it locally, but strange that I'm the only one having issues
[17:52] <ubitux> does this differ from libav?
[17:53] <ubitux> i have no idea about the source of your issue
[17:55] <kurosu> i haven't tested libav in months, but I could rerun to compare
[17:55] <kurosu> will do that after I actually managed to build something
[18:05] <kurosu> $ make ffmpeg.exe
[18:05] <kurosu> make: *** No rule to make target `ffmpeg.exe'.  Stop.
[18:05] <kurosu> huh
[18:05] <kurosu> make ffmpeg does the same thing
[18:06] <ubitux> make distclean, run configure again
[18:06] <kurosu> did that before running configure
[18:06] <ubitux> but your env might be broken anyway
[18:07] <kurosu> i'm going to check libav then
[18:07] Action: ubitux never built ffmpeg on windows so can't help
[18:11] <michaelni> i did build it in cygwin on windows a while ago and that worked
[18:17] <kurosu> libav compiles fine and passes fate-aac
[18:18] <ubitux> does the code where it fails differ?
[18:18] <kurosu> already switched to the ffmpeg branch to retest
[18:19] <kurosu> config.mak seems very dissimilar between ffmpeg and libav
[18:20] <ubitux> config.mak is a generated file
[18:20] <kurosu> and the strange code causing the issue for me in ffmpeg comes from that file
[18:20] <kurosu> oh
[18:20] <kurosu> common.mak sorry
[18:20] <ubitux> where does it fail?
[18:20] <kurosu> config.mak content seems to come partly from common.mak, seeing the troublesome lines
[18:21] <michaelni> some of the common.mak code is in Makefile in libav
[18:21] <kurosu> not a strict failure in fact, just spamag
[18:21] <kurosu> $(eval override $(VAR) = $$(call ECHO,$(VAR),$$(MSG)); $($(VAR))))
[18:21] <kurosu> I think
[18:21] <kurosu> causes the issue
[18:21] <kurosu> erm, already removed the @ in those
[18:22] <kurosu> redoing make distclean and rechecking the line
[18:22] <ubitux> libav has the same code in /Makefile
[18:23] <ubitux> it's a bit hard to guess what is causing a problem from what you say
[18:23] <kurosu> yeah, I understand that
[18:23] <kurosu> but I have no clue either
[18:24] <durandal_1707> perhas he have left files
[18:24] <kurosu> I'm just inferring the root of the issue, not knowing what causes it
[18:24] <kurosu> yeah
[18:24] <ubitux> you can also use git clean in case you don't trust make distclean
[18:25] <michaelni> trying a completely fresh checkout of ffmpeg in a seperate directory is an option as well if there are no better ideas
[18:26] <kurosu> I'm afraid of running git clean, if that removes any file that isn't under git control
[18:26] <durandal_1707> git status
[18:26] <ubitux> that's indeed what's in gonna do :p
[18:26] <kurosu> I have test files, patches, scripts and so on
[18:26] <durandal_1707> git stash
[18:26] <ubitux> durandal_1707: won't work
[18:27] <durandal_1707> rsync
[18:27] <kurosu> I'm probably not going to stash the several MB if not even GB files, I guess
[18:27] <durandal_1707> why you put them in first place ....
[18:28] Action: ubitux also put various files in the current ffmpeg directory
[18:28] <kurosu> that's kind of an offensive question, and I don't want to reply in a rude way
[18:29] <durandal_1707> do good old way: create patch and manually apply them, hoping that nothing is missing
[18:29] <kurosu> i think it was cruft left by libav conf
[18:29] <kurosu> destroying the folder where I configured things solved the isses
[18:30] Action: michaelni also has tons of crap in his ffmpeg directory :)
[18:30] <kurosu> I have m64 and m32 build dirs as well as other ones to quickly switch between arches
[18:31] <kurosu> probably a fluke
[18:32] <kurosu> i think I'll just set additional buil dirs for ffmpeg config, that should avoid such issues
[18:33] <durandal_1707> than beware if somone adds "git clean -f" as make target one day....
[18:35] <ubitux> that would be evil
[18:35] <kurosu> ok everything is fine now
[18:35] <kurosu> win32 passes fate-aac
[18:35] <michaelni> ubitux, true but it would finally cleanup my directory ;)
[18:35] <ubitux> :D
[18:46] <kurosu> ok, win64 also passes fate-aac
[18:47] <kurosu> ok, now on to solve that PIC issue
[18:48] <kurosu> I don't have any system around to test it though (or I have, but it's almost dead)
[18:50] <kurosu> btw, once I have changes in one branch (based on one project) and not in another (based on another project), how can I import/merge/... said changes into said another branch ?
[18:54] <Compn> might want to ask in #git or other git help channel :)
[18:55] <durandal_1707> cherry-pick?
[18:58] <saste> someone knows when we broke the filtering intro example?
[18:58] Action: ubitux doesn't keep an history of broken things
[19:02] <durandal_1707> saste: add examples from doc to fate
[19:14] <saste> ubitux: I blame you! -> 80a9297b
[19:14] <saste> ;-)
[19:15] <saste> but the example seems purposedly confusing
[19:17] <ubitux> ow.
[19:17] <ubitux> sorry :D
[19:17] <saste> not really, it was already broken
[19:17] <saste> but i remember it was working at some point in the far past
[19:18] <ubitux> maybe i broke it already previously
[19:19] <durandal_1707> so can same effect be made again? just update it
[19:20] <ubitux> saste: btw, if you're reworking that part
[19:20] <saste> ubitux: i'm reviewing a patch
[19:20] <ubitux> it would be nice to mention (more obviously) that the label names are arbitrary
[19:20] <saste> on that area
[19:21] <ubitux> and some are special names
[19:21] <durandal_1707> anyone know what to answer to comunnity question on g+?
[19:23] <Compn> whas the community question? (i'm not on g+)
[19:24] <Compn> if you could paste it for me perhapse? 
[19:26] <durandal_1707> http://stackoverflow.com/questions/15812463/ffmpeg-decoding-progress-during-frame-extarction
[19:28] <Compn> probably easiest is to throw a printf in vf_select
[19:35] <cone-236> ffmpeg.git 03highgod0401 07master:39406ea321ce: avutil/opencl: add check for the program number to create kernel
[19:35] <cone-236> ffmpeg.git 03highgod0401 07master:322428c85198: avutil/opencl: check strtol for failure
[19:35] <cone-236> ffmpeg.git 03highgod0401 07master:cfaffb1ab7de: avutil/opencl: replace assert by check and error message in av_opencl_init()
[19:49] <ubitux> about the consulting patch, i'll apply tomorrow
[19:49] <ubitux> luca is ok, and diego is ignoring me
[19:54] <saste> ubitux, fine with me
[20:00] <saste> michaelni, regarding the opencl buffer question, what's a proper design for passing H/W buffers?
[20:04] <michaelni> saste, i was thinking about that myself, and iam not sure, i can see several solutions
[20:05] <michaelni> from a new pixfmt, over using pointers 5,6,7(8) to a pix fmt seperate field in AVFrame
[20:05] <michaelni> and there are probably more :)
[20:05] <saste> michaelni, i never worked with H/W acceleration, so I have really no experience with that
[20:05] <saste> and seems we don't allow H/W pixel formats in libavfilter
[20:06] <michaelni> one thing to consider is that a opencl based decoder should be able to pass its buffers to avutil without having to memcpy them twice
[20:14] <ubitux> michaelni: oh thx for the ressources.
[20:25] <saste> uh smptebars broken??
[20:32] <saste> durandal_1707, since how much time was smptebar broken?
[20:32] <saste> or in other words, why did it broke?
[21:24] <cone-236> ffmpeg.git 03Nicolas George 07master:83affcde5124: lavc: use packet duration for subtitles if necessary.
[21:24] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:0a512e347fb2: Merge remote-tracking branch 'cigaes/master'
[22:01] <saste> ^^ people please put the commit hash in a ticket resolution
[22:02] <saste> so a user reading a closed bugreport knows where to look in the log
[22:02] <saste> "fixed by X" doesn't help much
[22:41] <durandal_1707> saste: add bot that do that automatically ....
[22:42] <durandal_1707> saste: dunno when smptebars got broken, at some random time it started to be broken for subsampled yuvs(funny) and at same or different time, colors become wrong (yellow is now orange)
[22:51] <durandal_1707> michaelni: can you ask highgod to put friendlier name in commit messages?
[22:53] <durandal_1707> saste: also because of drawutils not supporting real yuv, i thinkink abut not using it at all
[22:53] <durandal_1707> and forcing only yuv formats for smptebars
[23:00] <durandal_1707> colors are ok if drawutils pick rgb as output format
[23:24] <durandal_1707> huh, i almost ignored spam
[23:32] <durandal_1707> kurosu: wasn't all this aac sbr dsp patches already reviewed. at least assembly parts?
[23:45] <cone-236> ffmpeg.git 03Michael Niedermayer 07master:0f8435c089e7: doc: document -v repeat
[23:50] <saste> ping on: cmdutils: look for negated boolean program options *before* subcomponents options
[23:51] <saste> so i'll push both patches
[00:00] --- Fri Apr  5 2013