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

[burek]

[01:26] <cone-550> ffmpeg.git 03Carl Eugen Hoyos 07master:0aded6bf028f: Support MPEG-2 video mov files with sample description mp2v.
[01:26] <cone-550> ffmpeg.git 03Carl Eugen Hoyos 07master:5d6fac114b5e: Support old qclp-in-mov files that do not store bytes_per_frame in the header.
[01:40] <cone-550> ffmpeg.git 03Dave Yeo 07master:e5858fef38fe: configure: Revert commit 5176e9651bda5182df008a1226e2484fdd809985
[02:37] <cone-550> ffmpeg.git 03Peter Ross 07master:a3a4d07d6ae5: avutil/pixdesc: set bayer pixfmt descriptor flags
[03:21] <Daemon404> ... lul
[03:21] <Daemon404> only comment is about fricken gpu decodin
[03:21] Action: Daemon404 sighs
[03:22] <BBB2> there's some less silly comments on hn
[03:22] <Daemon404> i saw
[03:23] <Daemon404> top comment has a misunderstanding about how youtube transcodes their videos
[03:24] <Daemon404> and also ignores the "no 32bit asm" thing
[04:34] <cone-550> ffmpeg.git 03Peter Ross 07master:7e23cfba765a: avcodec/rawdec: for 16-bit pix fmts, shift pixels when bits_per_coded_sample < 16
[04:34] <cone-550> ffmpeg.git 03Peter Ross 07master:02b63246cf7f: libswscale: bayer to rgb24 & yv12 colorspace converters
[11:01] <aca> Hi. I've sent my Debian packaging of FFmpeg to the RFP bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#410
[11:02] <ubitux> yay
[11:02] <aca> But the security team seams unwilling to have both FFmpeg and libav in Debian.
[11:02] <aca> Even more, they seem to think libav is more secure than FFmpeg, because FFmpeg has more experimental code. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#435)
[11:03] <aca> Do you have any solid numbers about security issues in FFmpeg/libav?
[11:04] <aca> And they think that the long term branches of libav are a major benefit of libav.
[11:04] <ubitux> aca: only j00ru report
[11:04] <ubitux> "Also ffmpeg hasn't have long term branches which is a major
[11:04] <ubitux> benefit of libav."
[11:04] <ubitux> huh?
[11:05] <nevcairiel> its debian, they like software that develops as slowly as they do
[11:05] <ubitux> well, isn't 1.2 branch still maintained?
[11:05] <nevcairiel> i think so
[11:05] <ubitux> it's not because we have more release than the older in sync with libav is not maintained
[11:05] <aca> How long will the current 2.1.3 be maintained?
[11:06] <nevcairiel> I don't think there are such plans
[11:06] <nevcairiel> its just maintained as long as its deemed useful
[11:06] <aca> So if it is in Debian stable, it's useful?
[11:07] <ubitux> note that we might have a release to somehow match with libav10
[11:07] <ubitux> (which we may maintain longer that 2.1.x?)
[11:08] <aca> ubitux, What do you mean with 'somehow match with libav10'?
[11:08] <ubitux> release around the same date
[11:08] <ubitux> so kind of api compatible
[11:08] <ubitux> (btw, didn't they release a beta or something?)
[11:08] <ubitux> aca: is Moritz part of the security team?
[11:08] <aca> Yes, they did.
[11:08] <aca> ubitux, yes
[11:09] <ubitux> what he says is pretty weird
[11:09] <aca> ubitux: He is the only one from the security team that has made any statement about the security of FFmpeg.
[11:10] <ubitux> "either because experimental code wasn't merged yet"  is "experimental code" refering to ffmpeg code not cherry-picked from libav?
[11:10] <aca> ubitux: I don't know. Perhaps you could ask Moritz in the RFP bug?
[11:10] <ubitux> "or because code was rewritten in libav"  everything libav rewrites ends up in ffmpeg anyway, so this is a weird statement as well
[11:11] <aca> Yes, I didn't understand that one.
[11:12] <ubitux> aca: well, if i start posting it will probably end up with flaming, so i'd better let someone else correct him :)
[11:12] <ubitux> and lastly, the long term branch statement makes no sense either
[11:12] <ubitux> it looks like he was brainwashed or something
[11:12] <ubitux> :(
[11:13] <aca> ubitux: OK. I don't want to see flames. I can respond to him, so let's collect some arguments.
[11:13] <ubitux> btw, Timothy raised a point about qt-faststart
[11:13] <ubitux> i forgot about the change he raised
[11:14] <ubitux> (f4d9148fe, qt-faststart speedup; "decreased the processing time on a sample file from 1600 seconds to 4 seconds")
[11:14] <ubitux> so it might be worth considering integration at some point
[11:14] <aca> ubitux: Yes, I plan to have a qt-faststart package that diverts the libav qt-faststart.
[11:14] <ubitux> the "limited usage" i was talking about is because now the mov muxer has a faststart flag, but it has its uses anyway
[11:14] <aca> But the security team concerns seem somewhat more important.
[11:15] <ubitux> sure
[11:16] <ubitux> aca: do you have vim btw?
[11:17] <aca> ubitux: vim the editor?
[11:18] <ubitux> yes
[11:18] <aca> yes, why?
[11:18] <ubitux> it's not security relevant, but... you might want to run this:
[11:18] <ubitux> for x in codec filter format device; do vim -E -d libav/libav$x/all${x}s.c ffmpeg/libav$x/all${x}s.c -c 'let g:html_no_progress=1' -c TOhtml -c "w! diff-${x}s.html" -c 'qa!'; done
[11:18] <ubitux> assuming libav/ and ffmpeg/ in current dir
[11:18] <ubitux> then look at the html generated
[11:29] <aca> ubitux: It shows a lot of missing features of libav, that FFmpeg has. That's the reason why we want FFmpeg back.
[11:30] <aca> ubitux: Thanks for sharing this command. I will send the output to the RFP bug.
[11:31] <ubitux> :)
[11:32] <ubitux> michaelni: diff_bytes_mmx seems to deal well with unaligned addresses here; any idea why?
[11:54] <aca> Is it true, that libav didn't fix the issues reported by Google, but FFmpeg did? http://googleonlinesecurity.blogspot.fi/2014/01/ffmpeg-and-thousand-fixes.html
[11:55] <ubitux> http://j00ru.vexillium.org/?p=2211 is more complete iirc
[11:56] <ubitux> "so even though some of the FFmpeg bugs might not apply to Libav, there are still many unresolved issues there which are already fixed in FFmpeg. Consequently, we advise users to use the FFmpeg upstream code where possible"
[11:56] <aca> ubitux: Thanks, one argument more.
[13:15] <michaelni> ubitux, about diffbytes, if callers dont align then writing an SSE version would be tricky
[13:19] <cone-688> ffmpeg.git 03Sylvain Fabre 07master:526049ce61d0: Issue-#3407 : Enhance precision for double to string conversion, useful for GEOTIFF double values
[13:52] <cone-688> ffmpeg.git 03Peter Ross 07master:dd5abb0bac21: avdevice/v4l2: add V4L2_PIX_FMT_SRGGB8
[13:52] <cone-688> ffmpeg.git 03Carl Eugen Hoyos 07master:5642dd41ccb9: Add more Bayer colour spaces to the video4linux2 device wrapper.
[13:56] <BBB> ubitux: oh we're on slashdot now
[13:57] <ubitux> BBB :)
[13:57] <ubitux> we're still on the front page on HN
[13:58] <kierank> ubitux: you are also on front page of reddit programming
[13:58] <ubitux> yeah they sync by themselves ;)
[13:58] <kierank> well I submitted it
[13:58] <ubitux> ah :D
[13:59] <BBB> yeah I saw that, ty :)
[13:59] <kierank> and slashdot
[13:59] <BBB> yay, thanks
[13:59] <Skyler_> the trio of hives of scum and villainy
[13:59] <Skyler_> congrats ^^
[13:59] <BBB> that's also true
[13:59] <BBB> so, which hevc decoder is fastest?
[14:00] <BBB> some people claim de265 is better than openhevc, is it?
[14:00] <smarter__> haven't tested that other decoder
[14:00] <BBB> Skyler_: I though news.y was sometimes not too awful? or am I behind?
[14:01] <smarter__> bu ffhevc has already decent speed due to multi-threading
[14:01] <Skyler_> I don't know, I'd consider them worse than proggit, from what I've seen
[14:01] <smarter__> it depends really, sometimes there are interesting dicussions there, sometimes just stupidity
[14:01] <Skyler_> I don't remember proggit having quite the same level of misogyny, racism, and "but why don't poor people just buy more money?!" outoftouchness
[14:01] <Skyler_> but it varies, yeah
[14:02] <Skyler_> it probably gets worse because it's not very programming-focused anymore; it's mostly startups and silicon valley get-rich-quick types, I think
[14:02] <BBB> proggit is reddit/programming?
[14:02] <Skyler_> yeah
[14:03] <BBB> ah, ok
[14:03] <kierank> well you saw the hacker news thread about the fuzzing
[14:03] <kierank> FFmpeg should be written in $obscurelanguage
[14:03] <BBB> "why don't you write ffmpeg in python"
[14:03] <BBB> "nobody needs performance, 20% slower is just fine"
[14:03] <BBB> I mean, that sentence has so many misconceptions that it's just +5 funny
[14:04] <JEEB> oh wait until you get to the clojure/haskell/scala folk
[14:05] <smarter__> Rust! :D
[14:05] <JEEB> rust actually kind of makes sense
[14:05] <smarter__> yeah
[14:52] <gix-> ubitux: for example the dxva configure structs are identical, but have a different name. so putting them into such an union would not require the d3d9 code.
[14:53] <wm4> what's the advantage of d3d11 over d3d9 for decoding?
[14:55] <JEEB> winphone and winrt I would guess?
[14:55] <JEEB> and better interop with d3d11 apis in general? not sure
[14:55] <gix-> yeah
[14:56] <gix-> and no need to load d3d9 if you're already using 11
[15:11] <Compn> aca : the security team answer about 'experimental code' is very vague. possibly he means the mplayer filters? which can of course be disabled and probably should for debian...
[15:12] <Compn> i mean, experimental equals all code not in the fork ? what ?
[15:12] <wm4> ffmpeg in debian?
[15:12] <Compn> or experimental equals all new features ? is ffmpeg not supposed to add new features ?
[15:13] <Compn> wm4 : yes, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203
[15:13] <wm4> oh nice
[15:18] <aca> Compn: The security team as a whole is probably rather indifferent about whether FFmpeg or libav is in Debian, they just don't want to have both.
[15:19] <Compn> fair enough
[15:23] <aca> Compn: Do you mean the filters in libavfilter/libmpcodecs? Why should they be disabled? Are they not tested well?
[15:23] <kierank> __av500__: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 your kind of epic thread
[15:23] <wm4> I wouldn't trust the libmpcodecs wrapper one bit
[15:25] <aca> kierank: Epic? Take a look at: https://bugs.debian.org/727708
[15:25] <kierank> aca: I knew what that was before i clicked it
[15:26] <kierank> I know av500 is an avid viewer of such threads
[15:27] <Compn> aca : its wrapper and mplayer code, it only contains filters that have not been ported to ffmpeg yet. so its very much a work in progress. they arent needed by most users i think.
[15:27] <wm4> work in progress for multiple years
[15:27] <aca> Compn: Which configure option disables them?
[15:28] <Compn> humm
[15:28] <wm4> and now it contains only filters which nobody cards about (proof: nobody wants to port them)
[15:28] <Compn> the difficulty is also increased on those filters :P
[15:30] <Compn> aca : something like --disable-filter=mp_filter i think
[15:31] <aca> Compn: I will try it, thanks.
[15:31] <Compn> those filters have been included in mplayer for years of course
[15:31] <Compn> and are still included
[15:32] <Compn> ffmpeg has more security experts running tests against it than running against mplayer :)
[15:32] <aca> mplayer is in no good shape in Debian.
[15:32] <JEEB> it's not in a good shape anywhere
[15:32] <Compn> i know, i help mplayer users on irc. so many distro problems :\
[15:33] <Compn> 'if you just compile from source, it will stop crashing' ...
[15:33] <Compn> i've been sending users to vlc as much as possible
[15:34] <Compn> or deb-multimedia repo
[15:34] <Compn> when possible
[15:34] <Mavrik> yeah, too bad VLC is a crashy piece of software as well -_-
[15:35] <wm4> does debian try to package mplayer with libav?
[15:36] <Compn> Mavrik : i havent noticed vlc crashes , but i use nightly builds
[15:36] <JEEB> it generally shouldn't crash :P
[15:36] <Compn> mplayer ffmpeg and vlc shouldnt crash, but distro versions do more often than self-compiled ones
[15:37] <JEEB> well, most of my *nix use of VLC is the debian/ubuntu packaging
[15:37] <Mavrik> well, I did use it as a long-running transcode process
[15:38] <Mavrik> never seen it crash as a desktop player or one-time use software tho :)
[15:51] <michaelni> aca, Compn about the libmpcodecs wraper, it probably contains bugs but as far as security is concerned iam not aware of any security issues in it also if there was one it would be very hard to exploit as first the user would have to use that filter
[15:53] <Compn> yes, of course. i was just trying to figure out what 'experimental code' meant
[15:53] <aca> michaelni: Thanks, so do you think it makes sense to enable them? I do not use them.
[15:54] <michaelni> i dont know, its more a question for the users
[15:56] <Compn> that is one reason people use ffmpeg over libav, for the filters
[15:56] <aca> If there are no security concerns about them, I would enable them, and wait for bug reports.
[15:56] <Compn> i agree , more features are better :)
[15:56] <aca> Compn: WARNING: Option --disable-filter=mp_filter did not match anything
[15:56] <Compn> hmm
[15:56] <aca> Doesn't matter, I will leave them enabled.
[15:56] <Compn> have to do ./configure --list-filters then find the name for it
[15:57] <aca> Compn: Probably mp?
[15:58] <wm4> <Compn> yes, of course. i was just trying to figure out what 'experimental code' meant <- maybe when e.g. hevc was marked as experimental?
[15:58] <wm4> libav merged hevc only later
[15:58] <wm4> so only ffmpeg had this "experimental" code for a while
[16:02] <ubitux> aca: --disable-filter=mp probably
[16:05] <smarter> wm4: I think the experimental flag was dropped very quickly
[16:06] <wm4> yeah, I'm just trying to guess what that debian guy meant
[16:07] <ubitux> does anyone knows if libav has branched out the v10?
[16:08] <ubitux> or if the final version will include all the changes from master
[16:08] <wm4> I think they made a branch, but who knows if that's the final one
[16:08] <ubitux> i'm asking to know if it would make sense to release now to be in sync
[16:08] <ubitux> or we have to wait until the final
[16:09] <smarter> there's a branch
[16:09] <ubitux> and that branch will only pick fixes from master so?
[16:09] <smarter> https://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/10
[16:09] <smarter> it should, but I guess there can be exceptions
[16:10] <ubitux> michaelni: should we have a "lts" release starting now so we can have a matching version of ffmpeg for libav10?
[16:14] <wm4> you should definitely try to have a matching release
[16:14] <wm4> and support it as long as libav10 is
[16:18] <michaelni> ubitux, we are a bit late already anyway with our 2-3 month per release schedule so yes
[16:22] <michaelni> ubitux, about matching,our major version for libavutil differs to libav10, so if someone wants truly matching he has to come up with some magic solution about that one
[16:23] <ubitux> well it was more about api, features & bugs
[16:23] <wm4> at this point it's a joke both projects use the same pkg-config names
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:8c6a976feeea: avcodec/takdec: always check bits_per_raw_sample
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:325feb8e0d51: avcodec/vc1: reset fcm/field_mode in non advanced header parsing
[17:47] <cone-688> ffmpeg.git 03Justin Ruggles 07release/2.1:a644272a4a95: samplefmt: avoid integer overflow in av_samples_get_buffer_size()
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:f91ef98c9d74: avcodec/wmalosslessdec: fix mclms_coeffs* array size
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:4a28a3ddc4eb: avformat/mpegtsenc: Check data array size in mpegts_write_pmt()
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:656770e2aacf: avcodec/hevc: make *ps_id unsigned
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:f8985cb9d995: avcodec/utils: set AVFrame format unconditional
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:4cc18ee5da11: avcodec/msrle: use av_image_get_linesize() to calculate the linesize
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:18eac12c6d47: avcodec/ansi: fix integer overflow
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:a94f36742405: avcodec/snow: split block clipping checks
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:c9b961748f79: avformat/flac_picture: allocate buffer padding for picture
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:e266fcf0834a: avformat/flac_picture: clear padding area
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:f22e88c17772: avcodec/mjpegdec: pass into ff_mjpeg_decode_sos() and check bitmask size
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:9368b91834e4: avcodec/vc1dec: field pictures with direct mode MBs, followed by frame pictures are not supported
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:10a30e4de561: avcodec/vc1: factor read_bfraction() out
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:ab1c7113f9ec: avcodec/vc1: Check bfraction_lut_index
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:ebc490e7445c: avcodec/tiff: reset geotag_count in free_geotags()
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:d79419d0f993: avcodec/hevc: propagate error code from hls_coding_quadtree()
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:9fb364babdc7: avcodec/aacdec: Fix pulse position checks in decode_pulses()
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:9330bcff9ba2: avcodec/h264: Disallow pps_id changing between slices
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:e7b7e6941686: avcodec/h264: update current_sps & sps->new only after the whole slice header decoder and init code finished
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:69f99f80d125: avcodec/hevc: clear tab_slice_address in hevc_frame_start()
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:b959e6393e8a: avcodec/hevc: hls_decode_entry: check that the previous slice segment is available before decoding the next
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:aa672f5e6af4: avcodec/hevc: clear tab_slice_address of ctb on error.
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:ce5d9a2b4b30: avcodec/hevc: make check for previous slice segment tighter
[17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:7034e808f6b2: avcodec/hevc_ps: Use get_bits_long() in decode_vui()
[17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:6341a7006d74: avcodec/alsdec: check predictor order against block length
[17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:d0d441b35053: avcodec/h264: more completely check the loop filter parameters
[17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:c8d363a3593a: avformat/bink: Check return value of av_add_index_entry()
[17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:846a9c67ff6e: avcodec/h264: use subsample factors of the used pixel format
[17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:ea7ccf374845: avcodec/mpeg4videodec: Check for bitstream overread in decode_vol_header()
[17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:2368d08e701a: Merge commit 'e22ebd04bcab7f86548794556c28ecca46d9c2ac'
[17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:0909b8acf8f7: avcodec/hevc: Simplify get_qPy_pred()
[17:53] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:d3139c9733f1: update for 2.1.4
[18:03] <aca> I'm trying to build the Debian package for Debian experimental, as I think an upload there would be good for testing purposes. But the acodec-flac test fails: Error while decoding stream #0:0: Invalid data found when processing input
[18:04] <aca> Any ideas which package could be at fault? Maybe gcc4.9?
[18:05] <michaelni> yes, very likely 4.9 related
[18:06] <aca> OK. I'll try depending on gcc-4.8.
[18:27] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:42361bdf51c4: avcodec/mpegvideo: fix buffer clear code so it should work with negative linesizes
[18:27] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:72e691314027: avcodec/h264: clear chroma planes when flags gray is used
[18:56] <ubitux> bayer support is completely pushed? :o
[18:58] <nevcairiel> looks like it
[19:43] <llogan> some people just don't ever understand. this is the 6th time I've told someone not to send user help questions to -devel...
[19:43] <llogan> setting to auto discard.
[20:44] <cone-688> ffmpeg.git 03Clément BSsch 07master:57ec555e8ef3: avcodec/pngenc: fix invalid read in sub filter.
[21:23] <Daemon404> does pross come on irc much?
[21:24] <nevcairiel> i've seen him around, not sure i would say much
[21:24] <Daemon404> hmm ok
[21:24] <Daemon404> im curious how he intends to handle the differing bayer patterns that every camera format in existed uses
[21:24] <nevcairiel> how many patterns can you really create
[21:25] <Daemon404> a lot apparently
[21:25] <Daemon404> sme formats even store them in metadata
[21:25] <Daemon404> i.e. they can be custom
[21:25] <nevcairiel> sounds quite unfun
[21:25] <ubitux> speaking of this, i'd love to see support for canon & nikon "raw" formats
[21:25] <Daemon404> which?
[21:25] <Daemon404> each hae lke 10 formats
[21:25] <Daemon404> that are 'raw'
[21:26] <Daemon404> new one every year
[21:26] <nevcairiel> add a libraw wrapper imho
[21:26] <nevcairiel> its too much pain to try to support this directly
[21:26] <Daemon404> and currently nothing decodes the c500 raw format
[21:26] <Daemon404> i cant even get their own software to do it
[21:26] <Daemon404> its a dir of files + 3 xml files
[21:26] <ubitux> cr2 for canon
[21:26] <ubitux> nef for nikon
[21:26] <ubitux> http://wildtramper.com/sw/cr2/cr2.html they use some bayer stuff
[21:26] <nevcairiel> libraw 0.16 claims support for canon c500, if thats what oyu mean
[21:26] <Daemon404> oic
[21:27] <Daemon404> nifty
[21:27] <Daemon404> especially since i could not find a spec.
[21:27] <Daemon404> orr even barely an acknowledgement of its existence
[21:27] <Daemon404> outside of PR
[21:27] <ubitux> it would be pretty cool for doing timelapse based on these raws
[21:28] <Daemon404> libraw wrapper sounds sanest
[21:31] <ubitux> the whole lib seems to fit on 4k lines of code unless i'm mistaken
[21:31] <Daemon404> im sure NIH will win as usual
[21:31] <ubitux> it doesn't look like an unbearable project
[21:31] <Compn> someone came in here talking about a camera raw format demuxer being added
[21:31] <Compn> i was asking about dcraw project , but he had his own code
[21:31] <Compn> if you want to check old logs search for dcraw...
[21:31] <ubitux> Daemon404: well, i'm not saying we should absolutely write our own, but it looks like an interesting project
[21:32] <ubitux> and since we have bayer, and a lot of helpers for doing such jobs in ffmpeg
[21:32] <ubitux> i would guess it probably fits as a builtin
[21:41] <llogan> i can probably get some raw samples from that weird blackmagic cinema camera if anyone wants them
[21:42] <Daemon404> kierank probably has loads already
[22:10] <cone-688> ffmpeg.git 03Luca Barbato 07master:50c988aa6d6c: hevc: Drop unnecessary shifts in deblocking_filter_CTB
[22:11] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:c2b5981afa4e: Merge commit '50c988aa6d6c6f0ceb8f922bcea34800b56b85d9'
[22:17] <cone-688> ffmpeg.git 03Luca Barbato 07master:ff486c0f7f6b: hevc: Do not right shift a negative value in get_pcm
[22:17] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:a2e4b23bfe2d: Merge commit 'ff486c0f7f6b2ace3f0238660bc06cc35b389676'
[22:23] <cone-688> ffmpeg.git 03Luca Barbato 07master:8eeacf31c5ea: hevc: Do not left shift a negative value in hevc_loop_filter_chroma
[22:23] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:1287b640f000: Merge commit '8eeacf31c5ea37baf6b222dc38d20cf4fd33c455'
[22:30] <cone-688> ffmpeg.git 03Janne Grunau 07master:5800ba0db667: configure: disable cpunop if the check fails
[22:30] <cone-688> ffmpeg.git 03Diego Biurrun 07master:96ea3dea5805: configure: Move cpunop into ARCH_EXT_LIST_X86
[22:30] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:38336f0fb10a: Merge commit '5800ba0db667630e6ff81d30f03961ea10726aa6'
[22:32] <kierank> bayer to yv12 is a bit weird
[22:41] <cone-688> ffmpeg.git 03James Almer 07master:10b0161d7814: x86: add missing XOP checks and macros
[22:41] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:098243325349: Merge commit '10b0161d78148f46eaffb29ea022378947eaef2c'
[22:42] <Daemon404> kierank, you mean evil
[22:42] <Daemon404> im sure.
[22:42] <kierank> seems weird
[22:42] <kierank> to convert from raw bayer rgb to a subsampled yuv format
[22:43] <Daemon404> ofc
[22:43] <Daemon404> i bet it will silentl go through yv12 if you try to convert to 4:4:4 too
[22:43] <Daemon404> would have made more sense to go to 4444
[22:43] <Daemon404> -4
[22:47] <cone-688> ffmpeg.git 03James Almer 07master:1b932eb1508f: x86: add detection for FMA3 instruction set
[22:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:d9574069c14a: Merge commit '1b932eb1508f550fac9e911923a0383efda53aa3'
[22:49] <nevcairiel> it has a direct path to rgb24, but we all know that swscale sucks at generic conversions. Well, at least it does generic conversions, which is why most people use it ... but it also sucks at it... :)
[22:58] <cone-688> ffmpeg.git 03James Almer 07master:d59fcdaff36e: x86: add detection for Bit Manipulation Instruction sets
[22:58] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:bd8d73ea8bb7: Merge remote-tracking branch 'qatar/master'
[23:09] <BBB> kierank: well yv12 is the internal sws format for indirect conversions
[23:09] <kierank> ah right
[23:09] <BBB> see, that was one thing the old imgconvert did better - indirect conversion
[23:10] <BBB> so it would do a shortest-path between known-direct conversions to do indirect conversions
[23:10] <BBB> I'm not saying it's faultless, but at least it was free-form
[23:10] <Daemon404> BBB, and as such we get evil silent passs through yv12
[23:10] <Daemon404> and fuck chroma
[23:10] <Daemon404> its happened to me so many times.
[23:10] <BBB> oh you guys watch chroma :-p
[23:10] <BBB> ;-)
[23:10] <BBB> I fully support that complaint, in fact, at some point I wanted to rewrite swscale
[23:10] <BBB> but fuck scaling, nobody uses that anyway
[23:11] <BBB> if vimeo wants to downsample input videos, pay someone to write a better one
[23:11] <BBB> I'm not going to do it for free, it has no direct use for me
[23:11] <Daemon404> i got yelled at for saying scaling should be decoupled last time
[23:11] <Daemon404> me == me personally
[23:11] <nevcairiel> the problem is that chroma conversion is scaling
[23:11] <Daemon404> not vimeo
[23:12] <Daemon404> nevcairiel, i referring to the mixeed scaling/conversion stuff filled with macros
[23:12] <Daemon404> not chroma
[23:12] <BBB> for you pesonally, I'd recommend just to ignore scaling and act like it doesn't exist
[23:13] <BBB> it's best for your heart
[23:14] <Daemon404> cant really, last time it hit me was rgb->444yuv conversion
[23:14] <Daemon404> which had an implicit pass through 420
[23:14] <nevcairiel> i only use swscale for converting rare/uncommon pixel formats, screw chroma on those :p
[23:14] <Daemon404> (which has since been fixed... i think)
[23:14] <Daemon404> yes everyone writes their own
[23:16] <nevcairiel> the only thing i really wrote is a yuv->rgb converter, because swscale either does point scaling or is *extremely* slow, everything else i wrote is just minor byte shuffling to conform to directshow pixel formats, which swscale doesn't do anyway
[23:16] <Daemon404> P010 and pals?
[23:17] <nevcairiel> (not to mention swscales problems with difference transfer matrixes and color ranges)
[23:17] <nevcairiel> Daemon404: yeah
[23:18] <nevcairiel> that reminds me that i wanted to offer rgb48 output from my rgb converter, instead of dithering the output
[23:19] <andrewrk> hello. Question about the compand audio filter. in compand_drain, why does ff_get_audio_buffer use FFMIN(2048, s->delay_count) ?
[23:19] <Daemon404> nevcairiel, how many renderers can even take that?
[23:19] <Daemon404> probably just madvr
[23:20] <nevcairiel> probably
[23:20] <nevcairiel> but its like 5 lines of code
[23:20] <nevcairiel> sowhynot
[23:20] <nevcairiel> probably a bit more lines since its sse2 intrinsics
[23:20] <nevcairiel> but not much more
[23:24] <andrewrk> also I see if (fabs(g1 - g2)) where g1 and g2 are doubles. Why not simply g1 != g2 ?
[23:24] <nevcairiel> because doubles
[23:24] <andrewrk> ah it does the epsilon check
[23:24] <ubitux> 0 vs -0 maybe
[23:24] <nevcairiel> one shall never check floating points for equality
[23:25] <andrewrk> but isn't "if (fabs(g1 - g2))" still checking floating points for equality? or is it ok because it casts down to floats, and that's why
[23:25] <andrewrk> if the 'f' was missing it would be not ok
[23:25] <ubitux> it's handling 0 and -0
[23:25] <ubitux> not a proper check though
[23:26] <ubitux> i guess
[23:26] <andrewrk> what would a proper check look like?
[23:26] <ubitux> i'd say something like fabs(g1-g2)<0.0001 or something
[23:26] <nevcairiel> there is constants for that
[23:26] <ubitux> (don't we have a builtin for that?)
[23:27] <ubitux> yeah but iirc there is compat concerns about using the epsilon constant
[23:27] <nevcairiel> i think i saw a builtin for that
[23:27] <ubitux> don't remember the details though
[23:28] <Daemon404> clearly you should have used fixed point
[23:30] <nevcairiel> if only fixed point would be easier to use :p
[23:30] <nevcairiel> i always get confused by some calculations in fixed point :(
[23:30] <Daemon404> or better yet
[23:30] <Daemon404> convert all the fp ops in ffmpeg to use mpfr
[00:00] --- Mon Feb 24 2014