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

[burek]

[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