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

[burek]

[00:00] <saste> well i can make the script shorter if you think that helps
[00:00] <michaelni> that wasnt what i meant 
[00:01] <michaelni> awk is wider availbale than perl i suspect
[00:02] <michaelni> also the build system is already complex
[00:08] <michaelni> also i dont understand why you need a script to recursively extract dependancies
[00:09] <michaelni> if x depends on y and y depends on z there should be no need for x to declare an explicit dep on z
[00:09] <michaelni> or maybe i misunderstand what you are trying to do
[00:11] <saste> michaelni, what it's happening: i edit z, but x is not updated
[00:12] <saste> this because currently the .d file only lists first level includes
[00:13] <saste> i can try to replace the perl script with awk, even if this will require some time (at least a few hours)
[00:15] <michaelni> its not so much perl i dislike than the need for this as such
[00:15] <beastd> saste: where do multi level includes happen currently? (i am just curious and you must have run into the problem somewhere i assume)
[00:16] <saste> beastd, for example: ffmpeg-devices->devices->indevs
[00:16] <saste> ffmpeg-codecs->codecs->decoders
[00:16] <beastd> ok, thx.
[00:17] <michaelni> btw, also cant the recursive stuff infloop if someone commits some buggy includes ?
[00:17] <saste> michaelni, we would notice that immediately
[00:18] <michaelni> yes, by having to manually fix all fate machines
[00:19] <saste> we can add a check to avoid loops
[00:19] <michaelni> i think that should be done if this is pushed yes
[00:57] <durandal_1707> who uses C++11?
[01:42] <ubitux> saste: both tests are with mp=
[01:42] <ubitux> afaict
[01:43] <ubitux> oh, i'm stupid
[01:43] <ubitux> i'm seriously tired.
[01:55] <durandal_1707> that idea that code should not be fixed bacause it will be slower is little strange
[01:57] <durandal_1707> by "non visible artifacts" it means artifact that do not show, or "artifacts" that are after right edge
[01:58] <durandal_1707> ?
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:7a2b6342205b: jpeg2000dec: simplify init_tile() / merge from j2k
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:20a2d5ec11da: jpeg2000dec: fix ff_mqc_initdec() and data setup order
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:f67f2681da5f: jpeg2000deci/j2kdec: fix sizeof types
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:a5203d86b36e: j2kdec: merge length==0 check from jpeg2000
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:cdb86136f764: j2k/jpeg2000: merge some of the tilepart related code
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:f471b5fa300e: j2k: restructure  bitstream decoding
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:45c0e338fc30: j2kdec: merge picture handling from jpeg2000
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:89f472b3ee2f: j2kdec: merge JPEG2000_PGOD_CPRL code from jpeg2000
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:5dbbb762e58c: jpeg2000dec: merge struct field types from j2k
[03:11] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:192050d7a7d5: jpeg2000dec: merge sgnd fix from j2k
[03:12] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:fd7e1190379d: jpeg2000dec: merge simplification of jpeg2000_decode_packets() from j2k
[03:12] <cone-514> ffmpeg.git 03Michael Niedermayer 07master:9d56ccf5af52: j2k/jpeg2000dec: merge
[03:46] <llogan> michaelni: what got you interested in the j2k/jpeg2000 lately?
[04:00] <michaelni> llogan, good question
[04:46] <Compn> i think we should make a news entry for icod , it was a codec wholly unsupported on linux 
[04:50] <Compn> did we get any feedback from broadcasters who are using ffmpeg more now ?
[04:50] <Compn> all those 10bit codecs :)
[05:40] <BBB> what is j2k vs. jpeg2000dec?
[05:41] <BBB> are there 2 decoders?
[05:41] <BBB> (that sounds kind of awkward)
[06:13] <Compn> BBB : yes there was the original gsoc j2k decoder
[06:13] <Compn> and then someone came along and sent a patch that was based on the gsoc j2k decoder, except it had new features and some cleanup/changes
[06:14] <Compn> so, since no one really wanted to work on j2k stuff at the time, michael added it as a second decoder
[06:15] <Compn> now michael decided to merge the two decoders, getting the best parts from each of them.
[06:16] <Compn> it was different enough from the original that the new patch author said it would be easier just to use his new one
[06:16] <Compn> and i guess , via testing, it was found that each decoder had strengths and problems. but it was non trivial to merge the two, as you can see from the commits
[06:17] <Compn> we still have two prores decoders, although the license gpl/lgpl (last i checked) was keeping it from being merged together
[06:18] <Compn> its hard trying to get everyone to work together and not reinvent the wheel :D
[06:18] <Compn> not sure how michael does it :)
[06:34] <Compn> fate is back to low numbers, good to see :)
[09:33] <nevcairiel> still plenty fate boxes that arent sending results to the new server
[09:46] <nevcairiel> hm vignette, sounds like something ubitux would do
[09:46] <nevcairiel> y u break msvc
[09:52] <nevcairiel> ah the freaking extra semicolon
[10:23] <cone-427> ffmpeg.git 03Clément BSsch 07master:7de8a38160d8: lavfi/vignette: remove extra semi-colon.
[10:23] <ubitux> nevcairiel: sorry about that
[10:23] <nevcairiel> ah neat i dont need to send a patch then
[10:24] <nevcairiel> i would've probably removed it from the use of the define, but shrug :)
[11:06] <michaelni> Daemon405, some of your fate boxes dont send data since a long time
[11:10] <michaelni> btw, anyone who has a old 32bit box (amd preferrably) and would be interrested in setting up a fate box ?
[11:10] <michaelni> iam asking as our duron is not healthy
[11:10] <michaelni> 5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always   FAILING_NOW 2855
[11:11] <av500> put a new drive
[11:11] <michaelni> iam too busy
[11:12] <michaelni> the box is used for nothing else than fate
[11:32] <ubitux> note: my fate instances will be down for a while
[11:33] <michaelni> ubitux, noted, but why ?
[11:35] <ubitux> well, because i suppose i suck at sysadmin
[11:35] <michaelni> ?
[11:35] <ubitux> i had to reboot the box, and since a lot happened since the last boot, it doesn't anymore :)
[11:35] <michaelni> :(
[11:36] Action: michaelni was planing to reboot the duron too to get fate back working and the disk out of read only
[11:37] <cone-427> ffmpeg.git 03Kostya Shishkov 07master:0b0953baecc5: proresenc: alpha coding support
[11:37] <cone-427> ffmpeg.git 03Michael Niedermayer 07master:f0b9bd807b15: Merge remote-tracking branch 'qatar/master'
[13:43] <cone-427> ffmpeg.git 03Michael Niedermayer 07master:c1415cfefb01: jpeg2000dec: print more detailed cdx/y debug info
[13:43] <cone-427> ffmpeg.git 03Michael Niedermayer 07master:f77467a11dbf: jpeg2000dec: fix indention
[13:54] <ubitux> michaelni: should be good
[17:29] Action: michaelni notes that irker/cone still is buggy
[17:37] <cone-193> ffmpeg.git 03Michael Niedermayer 07master:6e073dd127f0: configure: check for nanosecond precission stat
[17:53] <saste> michaelni, so, what should i do with mcdeint, ok to commit?
[17:53] <saste> alternatively, i can port it and then modify it in lavfi once the wrapper is dropped
[18:11] <michaelni> saste, i see no problem with commiting it, i assume you tested it and it works and is similar in speed to libmpcodecs
[18:11] <saste> michaelni, yes, i sent my benchmark on list
[18:11] <saste> there is ~1% slowdown
[18:12] <michaelni> for the edge change but i meant libmpcodecs vs libavfilter 
[18:13] <saste> i wanted to understand the diff issue
[18:14] <saste> thus my plan is: commit mp/mcdeint fix so it can easily backported to mplayer, commit mcdeint port and drop mp/mcdeint
[18:14] <ubitux> and then write swblend please, with support of rotation please
[18:14] <ubitux> :)
[18:15] <michaelni> saste, iam not sure we misunderstand each other but did anyone benchmark the port against the original libmpcodecs ?
[18:21] <saste> michaelni, it's basically the same code, i don't expect any measurable difference
[18:22] <saste> michaelni, also what do you plan to do with the opencl scale patch?
[18:28] <michaelni> saste, feel free to review the scale patch if you want
[18:53] <BuxiNess> michaelni, I tried your patches ... Really good job!
[18:54] <BuxiNess> I play the video in full res (with 24 threads in 12 cores) with almost no frame drop 
[18:55] <BuxiNess> juste the weird thing, is the xyz2rgb filter is no more automaticaly set with avplay
[18:55] <BuxiNess> But, the video in ful res again : Youhou!
[18:55] <ubitux> xyz2rgb filter?
[18:55] <ubitux> there is a native support in sws
[18:56] <ubitux> and you certainly mean ffplay ;)
[18:56] <BuxiNess> ubitux, yes but its no more set with avplay $INPUT
[18:56] <BuxiNess> yep ffplay sorry
[18:58] <BuxiNess> sorry I use the wrong ffplay :-) the installed one, not the head one, so filter works fine
[19:01] Action: microchip_ bought a bluray player :)
[19:01] <nevcairiel> BuxiNess: did you ever finish porting the sse idwt? would love some more speed :)
[19:02] <BuxiNess> nevcairiel, not yet 
[19:02] <BuxiNess> and yes the 1st test show more spped
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:afa30e51d1ab: ftp: formatting and typos fixes
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:80cce899f62c: ftp: rename function name
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:e46e49e31d7e: ftp: credentials moved into FTPContext
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:c84d6aa2f63f: ftp: move create control connection to function
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:1931c2d2654f: ftp: reconnect on read
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:3f0052180990: ftp: enhanced status code handling
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:d99beeb70e08: ftp: move common commands code to function
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:34c423894ceb: ftp: reconnect on seek
[19:28] <cone-193> ffmpeg.git 03Lukasz Marek 07master:ddbcc48b6467: ftp: enhanced error handling
[19:28] <cone-193> ffmpeg.git 03Michael Niedermayer 07master:f70d0212ce13: Merge remote-tracking branch 'lukaszmluki/master'
[21:22] <gnafu> microchip_: What model?  Does it use ffmpeg?  ;D
[21:22] Action: gnafu has a Panasonic that runs Linux, but he doesn't think it uses ffmpeg at all.
[21:24] <microchip_> gnafu: LG BP620
[21:30] <llogan> cehoyos: mpng.avi looks even weirder with ffplay.
[21:31] <cehoyos> weirder than "completely broken"?
[21:32] <llogan> depends on your definition of "completely broken".
[21:33] <cehoyos> Would you prefer another wording?
[21:33] <cehoyos> (or suggest)
[21:37] <llogan> ah, nevermind. i was using the wrong ffmpeg build. i have too many...
[21:37] <cehoyos> llogan: I don't see much difference between ffplay and ffmpeg output for the sample from ticket 2618 - what do you mean?
[21:37] <cehoyos> ok
[21:37] <llogan> sorry, user error
[21:38] <cehoyos> If you can reproduce the issue and the regression, please set the ticket to "open" and "reproduced"
[21:39] <durandal_1707> cehoyos: you can't
[21:39] <durandal_1707> ?
[21:39] <llogan> traditionally another dev does it to confirm.
[21:41] <cehoyos> llogan: Compilation takes only a minute for you?
[21:46] <llogan> cehoyos: older source does. recent about 1.5 with just --enable-gpl
[21:47] <llogan> michael is faster: https://ffmpeg.org/trac/ffmpeg/wiki/CompileBenchmarks
[23:15] <cone-523> ffmpeg.git 03James Almer 07master:6510686c1663: lavf/tta: check header and seek table checksum
[23:15] <cone-523> ffmpeg.git 03Paul B Mahol 07master:710940bec168: tta: stop checking header checksum in extradata
[23:17] <Daemon404> humm
[23:18] <Daemon404> can ffmpeg do webp (via libvpx) ?
[23:18] <Daemon404> encoding i mean
[23:19] <Daemon404> further more... BBB-work -- does google discourace use the libvpx tarballs?
[23:19] <Daemon404> am i reall just supposed to use HEAD?
[23:56] <cehoyos> michaelni: Trac is down
[23:59] <ubitux> seems up
[00:00] --- Sat Jun  1 2013