[00:39] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/1.2:930d035e72ca: update for 1.2.2 [01:25] <KGB> 01[13FFV101] 15michaelni pushed 2 new commits to 06master: 02http://git.io/JUTNUg [01:25] <KGB> 13FFV1/06master 146eeb731 15Michael Niedermayer: ffv1/3.1: Fix punctuation to make the text understandable [01:25] <KGB> 13FFV1/06master 14924e9d3 15Michael Niedermayer: ffv1/3.1: The border is about slices not pictures [03:06] <cone-656> ffmpeg.git 03Marton Balint 07fatal: ambiguous argument 'refs/tags/n1.2.2': unknown revision or path not in the working tree. [03:06] <cone-656> Use '--' to separate paths from revisions [03:06] <cone-656> refs/tags/n1.2.2:HEAD: lavc: do not override format if neither text nor bitmap codec prop is set [03:35] <cehoyos> mateo: Regarding vaapi with ffplay, I don't think SDL supports any hardware acceleration, I would have to get OpenGL support to ffplay first (which would also allow VDPAU support) [04:10] <cone-656> ffmpeg.git 03Nicolas Bertrand 07release/2.0:e0d88cfd1818: jpeg2000: Initialize only once mqc arrays [04:10] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:fa6b6dad3d78: jpeg2000: fix overflow in dequantization [04:10] <cone-656> ffmpeg.git 03Carl Eugen Hoyos 07release/2.0:09b33f9a8251: Fix pix_fmt detection in the native jpeg2000 decoder. [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:9da9b36435c9: jpeg2000dec: parse CDEF [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:8b221d60fa5e: jpeg2000dec: Support non subsampled 8bit planar pixel formats [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:9a6d3eee5995: jpeg2000dec: silence unused variable warning [04:11] <cone-656> ffmpeg.git 03Nicolas Bertrand 07release/2.0:e0d88cfd1818: jpeg2000: Initialize only once mqc arrays [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:d73ce6cb5609: jpeg2000dec: Support non subsampled 9-16bit planar pixel formats [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:fa6b6dad3d78: jpeg2000: fix overflow in dequantization [04:11] <cone-656> ffmpeg.git 03Carl Eugen Hoyos 07release/2.0:09b33f9a8251: Fix pix_fmt detection in the native jpeg2000 decoder. [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:9da9b36435c9: jpeg2000dec: parse CDEF [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:8b221d60fa5e: jpeg2000dec: Support non subsampled 8bit planar pixel formats [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:9a6d3eee5995: jpeg2000dec: silence unused variable warning [04:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07release/2.0:d73ce6cb5609: jpeg2000dec: Support non subsampled 9-16bit planar pixel formats [11:34] <cone-858> ffmpeg.git 03Diego Biurrun 07master:966689442ed8: buffersink: K&R formatting cosmetics [11:34] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:edab63a4067a: Merge commit '966689442ed843019dc0722a49bfb0ac51755d19' [11:53] <cone-858> ffmpeg.git 03Diego Biurrun 07master:16c22122c788: h264: K&R formatting cosmetics [11:53] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:102397d2c14d: Merge commit '16c22122c788b5e54a2f2e224bd0106429f0714c' [11:58] <cone-858> ffmpeg.git 03Diego Biurrun 07master:37063714c0a0: build: Only check FATE dependencies when running FATE tests [11:59] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:1ecf380223b0: Merge commit '37063714c0a064808f9671ec4d376955d664f463' [13:12] <cone-858> ffmpeg.git 03Luca Barbato 07master:10aa44aa675e: avidec: K&R formatting cosmetics [13:12] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:d78122099113: Merge commit '10aa44aa675e05067845e3e55fac37642cbbdae4' [13:23] <cone-858> ffmpeg.git 03Luca Barbato 07master:c8f0b20b4a6b: avidec: Let the inner dv demuxer take care of discarding [13:23] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:3afcddcff2bc: Merge commit 'c8f0b20b4a6bb6691928789d83e4b02896969848' [13:29] <mateo`> hi guys [13:30] <mateo`> in which case s->oformat can be NULL in the mov muxer ? (lines 3541, 3550) [13:34] <cone-858> ffmpeg.git 03Diego Biurrun 07master:6ff15cd569e1: Remove unreachable returns [13:34] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:2655c1ac1282: Merge commit '6ff15cd569e1345bc3612fb69ad3003b104fe50d' [13:43] <cone-858> ffmpeg.git 03Diego Biurrun 07master:5b097399baa2: eval: Explicitly ignore return value of strtod() in parse_db() [13:43] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:8ff23f0e3c9a: Merge commit '5b097399baa2e38cc513939cfab3a9b6fdbc33df' [13:51] <cone-858> ffmpeg.git 03Diego Biurrun 07master:bf4b0ed1d5d3: Add missing deprecation attributes [13:51] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:b0edd5999404: Merge commit 'bf4b0ed1d5d323050a87c9f0ad1dd40860eb3da2' [14:04] <mateo`> s->oformat seems not to be check in matroskaenc [14:21] <cone-858> ffmpeg.git 03Diego Biurrun 07master:270d7e3a1802: doc: cosmetics: Consistently format list and table items [14:21] <cone-858> ffmpeg.git 03Michael Niedermayer 07master:f0308af5fac9: Merge remote-tracking branch 'qatar/master' [14:35] <michaelni> mateo`, maybe the oformat checks are unneeded [14:36] <mateo`> it seems like, i will send a patch [15:51] <saste> any XML expert around? [16:27] <BBB> ubitux: Daemon404: let's talk logistics, when do you guys want to start? next week monday (i.e. in 8 days)? [16:28] <BBB> ubitux: Daemon404: then second, I've written a skeleton (keyframe bitstream parsing and some minor parts of keyframe reconstruction), shall I upload that to my github so we can work on such a branch together? [16:40] <cone-858> ffmpeg.git 03Stefano Sabatini 07master:18df69d238fb: doc/ffprobe.xsd: specify tag elements in stream after disposition element [16:40] <cone-858> ffmpeg.git 03Stefano Sabatini 07master:2fcd400669bc: ffprobe: do not treat array elements as nested in the compact writer [16:40] <cone-858> ffmpeg.git 03Florent Tribouilloy 07master:2186a7e547fd: ffprobe: add -show_programs option [16:47] <Daemon404> BBB, that depends when i can mov e into my flat in london [16:47] <Daemon404> which i should find out tomorrow at latest [17:05] <BBB> Daemon404: ok I guess.. any interest in me pushing an early nonworking branch to github? [17:06] <Daemon404> BBB, actually im technically unemployed for 2 weeks or so in aug (while i transfer) [17:06] <Daemon404> so i should have time [17:06] <Daemon404> soon... sh [17:06] <BBB> lol [17:06] <Daemon404> ish* [17:06] <Daemon404> i also mostly finished The H.264 Book [17:06] <Daemon404> thought i got lost in the CABAC chapter [17:07] <Daemon404> though* [17:07] <BBB> that's ok, cabac is already implemented [17:07] <BBB> so is vp8/9/5/6's rac coder [17:07] <Daemon404> entropy coding didnt change? [17:07] <BBB> not the base part [17:07] <BBB> the use in the codec did, of course [17:07] <BBB> and it added adaptivity at a higher layer [17:07] <BBB> but the lowlevel part is identical [17:07] <Daemon404> k [17:12] <cone-858> ffmpeg.git 03Matthieu Bouron 07master:ee4ef139e361: lavf/movenc: remove useless checks on AVOutputFormat [17:12] <cone-858> ffmpeg.git 03Matthieu Bouron 07master:8a0919554502: lavf/movenc: improve psp check [17:25] <kurosu_> BBB / Daemon404: what codec are you discussing about ? [17:26] <JEEB> vp9 [17:26] <BBB> kurosu_: we want to write a native ffmpeg decoder in august [17:27] <kurosu_> ah ah ok, you want to beat hevc on another topic then :) [19:27] <cone-858> ffmpeg.git 03Carl Eugen Hoyos 07master:ae4dc0b37aa8: Set bits_per_raw_sample when decoding mjpeg / ljpeg. [19:27] <cone-858> ffmpeg.git 03Carl Eugen Hoyos 07master:7e8e8ba9cc2b: Assume gray8 if 1 < maxval <= 255 in pgm. [19:27] <cone-858> ffmpeg.git 03Carl Eugen Hoyos 07master:7651c0e49b1f: Avoid overflows when reading pgm files with maxval != 255 and != 65535. [20:47] <cehoyos> It is possible that both 7651c0e and a0348d0 are wong [20:47] <cehoyos> I am not sure how to test [20:50] <durandal_1707> uhh 7651c0e looks like workaround for bug in libjpeg [20:50] <cehoyos> "The most significant byte is first." - does that imply big endian? [20:52] <cehoyos> See http://netpbm.sourceforge.net/doc/pgm.html "9." [20:54] <durandal_1707> cehoyos: pnm code have big-endian variants only [20:54] <durandal_1707> so more 1 byte its in big-endian [20:55] <cehoyos> Which on of these is big-endian (assuming 12 bit): "02 d0" or "d0 02"? [21:02] <durandal_1707> big endian system reads bytes from left to right [21:22] <durandal_1707> did we get bankrupt? [22:00] <cone-858> ffmpeg.git 03James Almer 07master:ac8e70d7358e: oggenc: Write stream metadata if available [22:11] <cehoyos> durandal_1707: a0348d0 definitely breaks some pgm's on little endian, do you want to fix it? I will then revert 7651c0e if you don't do it. [22:12] <cehoyos> av_le2ne16() cannot be correct on both le and be if the pix_fmt is gray16be in both cases [22:12] <cehoyos> av_be2ne16() cannot be correct on both le and be if the pix_fmt is gray16be in both cases [22:15] <durandal_1707> cehoyos: what pgms? [22:16] <durandal_1707> your "patch" that get commited did not fix anything, it just introduced regression, because now ffmpeg decoder incorrectly some pnm files [22:24] <alsu> I have an rtmp stream which works with flvstreamer but not ffmpeg. should I file a bug with ffmpeg? [22:24] <cehoyos> The patch was not correct but It did not introduce a regression, the regression was there since a0348d0 [22:25] <alsu> happy to try and debug it too, if I can be of use [22:25] <cehoyos> There are no pgm's that were decoded correctly on le since a0348d0, current FFmpeg decodes libjpeg's broken pgm's correctly. [22:25] <cehoyos> No pgm [22:25] <cehoyos> No pgm's with 255 < maxval < 65535 [22:25] <durandal_1707> nonsense [22:26] <durandal_1707> as i already said ffmpeg does correctly decodes netpbm images with maxval != 255 & maxval !=65535 [22:30] <cehoyos> Yes, on be; on le, it is not correct. Note that av_be2ne16() cannot be correct on both be and le for the same colourspace [22:31] <durandal11707> and where is av_be2ne called? [22:33] <cehoyos> grep av_be2ne libavcodec/pnmdec.c ? (Note that the call is visible in my patch that you don't like.) [22:34] <durandal11707> cehoyos: your patch is wrong [22:34] <cehoyos> YES [22:35] <durandal11707> and code in pnmdec is worse than it was before [22:35] <cehoyos> Please fix the regression you introduced, you can either revert my patch, or I will do it when I backport your fix. [22:35] <durandal11707> and upgrade =2 silly obscure crap is wrong too [22:35] <cehoyos> I don't disagree, but before a0348d0 the "crap" worked, it is broken since [22:35] <durandal11707> cehoyos: your claim that i break pgm decoder for maxval != 65535 [22:36] <cehoyos> No for 255 < maxval < 65535 [22:36] <durandal11707> i'm telling you that i broke nothing that was not already broken [22:37] <durandal11707> cehoyos: there is ticket on trac that explains why maxvals: 255<maxval<65535 & 0<maxval<255 are not decoded correctly [22:39] <cehoyos> Wow, that's cool: You first broke decoding, then you reported it and nobody tested it for a regression;-) [22:40] <cehoyos> otoh: This ticket is about ppm, I was only talking about pgm, so I don't think these are related. [22:41] <durandal11707> not at all, decoding was never correct [22:41] <cehoyos> To shorten this: Do you want to fix the regression or not? [22:41] <cehoyos> It worked fine before (and it still works fine with avconv) [22:41] <durandal11707> also calling av_be2ne16 for each pixel is smart too [22:43] <durandal11707> cehoyos: do whatever you want, but be aware I may rewrite anything stupid i find [22:47] <cehoyos> That is exactly why I ask you: Do you want to fix the regression you introduced? [22:47] <cehoyos> (And additionally: Do you want to send patches for review?) [22:51] <durandal_1707> cehoyos: i'm against revert, as setting pix_fmt and than changing it is bad practice [23:00] <durandal_1707> nice, i get enormous spam when building [23:01] <durandal_1707> bunch of input/output_count [23:07] <cehoyos> durandal_1707: I am not sure I understand: Do you mean we should not revert my patch? Or we should leave the regression because fixing bugs is "bad practice"? (Sorry, I really don't understand.) [23:08] <durandal_1707> cehoyos: i was talking about reverting my patch [23:08] <cehoyos> So why are you against reverting your patch? [23:09] <durandal_1707> because seting pix_fmt, than checking pix_fmt and seting it again is bad practice [23:09] <durandal_1707> it should be set in single place [23:09] <cehoyos> So do I understand correctly that you want to fix the regression differently? That is perfectly fine with me. [23:10] <durandal_1707> yes [23:10] <cehoyos> Great, when will you do it? [23:11] <durandal_1707> i can do it, and give whole commit authorship to you [23:11] <cehoyos> Why? (I don't understand.) [23:13] <durandal_1707> because you found it [23:14] <cehoyos> Then please give me creadit for finding the issue if you want, just fix it;-) [23:15] <durandal_1707> but you also provided solution for problem [23:16] <cehoyos> Really? (I intentionally didn't.) [23:23] <durandal_1707> can pnms be read with netpbm ? [23:30] <durandal_1707> cehoyos: also what about pams with maxval < 65535 ? [23:30] <durandal_1707> pams with depth 1 [23:32] <cehoyos> What about pams? I am not sure I understand. [23:32] <cehoyos> (I thought a0348d0 only affected pgm's) [23:33] <durandal_1707> 7e8e8ba9cc2b074b988e8ab28f69cfc5d454d674 changed pam code [23:35] <cehoyos> It only affects images with maxval < 255 but the regression I mentioned above only appears for maxval > 255 [23:36] <durandal_1707> regression only broke pgms not pams [23:37] <cehoyos> That is what I am saying, yes. And 7e8e8ba also only affected pgm's, so how is this related to pam's ? [23:37] <durandal_1707> no 7e8.. affects only pams [23:38] <cehoyos> Afaict, it only affects pgm's, but if you have a pam that gets affected, I'd love to see it. [23:39] <durandal_1707> cehoyos: it changes only pam's code [23:40] <durandal_1707> pgms are type 5 [23:45] <cone-858> ffmpeg.git 03Paul B Mahol 07master:768e40b451a4: Revert "pnm: remove nonsense code" [23:51] <cehoyos> You are right, the commit message is not correct, it fixes pam decoding. [23:59] <cehoyos> Your commit message is only marginally better;-( (255 < ...) [23:59] <cehoyos> Why did you revert the patch? [00:00] --- Mon Jul 29 2013