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

[burek]

[00:01:19 CEST] <kierank> rkern: how?
[00:06:03 CEST] <rkern> I'd create a simple test app, run a short encode with dummy frames (one for each encoder param), then decode those frames and verify the params.
[02:48:39 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07release/3.0:512c064cd9e0: avformat/mux: Check that deinit is set before calling it
[02:48:40 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07release/3.0:f2e9e4757f7d: avfilter/vf_drawtext: Check return code of load_glyph()
[02:48:41 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07release/3.0:4c896d6bd478: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3
[02:48:42 CEST] <cone-124> ffmpeg 03Jan Ekström 07release/3.0:666754c66571: pgssubdec: fix subpicture output colorspace and range
[02:49:04 CEST] <michaelni> JEEB, backported to a few release branches (and pushed 3.0)
[06:19:22 CEST] <kierank> rkern: but how will you get Mac hardware on osx
[06:19:34 CEST] <kierank> Aws*
[13:41:18 CEST] <cone-104> ffmpeg 03Vicente Olivert Riera 07release/3.0:a5638dbfbafd: mips: add support for R6
[13:41:19 CEST] <cone-104> ffmpeg 03Shivraj Patil 07release/3.0:83eaaae0057f: configure: build fix for P5600 with mips code restructuring
[14:30:52 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:492d229303a8: qsvenc_hevc: Fix usage of ff_hevc_extract_rbsp
[14:57:26 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:fa936a307f5c: hevc_parse: rename into h2645_parse
[14:57:28 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:3c4ca4c5d799: Merge commit 'fa936a307f5cddfc2664600157a8207ca8080af6'
[15:01:58 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:8229eff4b7a9: h2645_parse: add a function for uninitializing the packet
[15:01:59 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:8e73574d4f17: Merge commit '8229eff4b7a98ae5d85bb75f3bb072781b4a8ebe'
[15:04:55 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:52ec149fbee5: h2645_parse: change the AVCodecContext* parameter to void*
[15:04:56 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:b5c10c4c9274: Merge commit '52ec149fbee57b6ca817049c9706212a0774a32c'
[15:08:11 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:b667252a41fb: h2645_parse: add support for parsing h264
[15:08:12 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:438ed974b832: Merge commit 'b667252a41fbf5a3f6ea8c67fdbc03db3d748977'
[15:15:10 CEST] <Daemon404> what is av_ctz and why does libav have it, and we don't?
[15:15:15 CEST] <Daemon404> (next merge makes use of it)
[15:17:02 CEST] <Daemon404> ah.. it is ff_ctz here.
[15:17:40 CEST] <rcombs> counts trailing zeroes
[15:18:41 CEST] <Daemon404> yeah i found this in git history
[15:18:49 CEST] <Daemon404> not sure why it is a public func in libav
[15:20:46 CEST] <rcombs> I don't think it actually is
[15:20:50 CEST] <rcombs> intmath.h isn't installed
[15:20:55 CEST] <Daemon404> ah
[15:21:00 CEST] <Daemon404> just oddly named
[15:21:05 CEST] <rcombs> so it's available av_prefixed because ?????
[15:21:22 CEST] <rcombs> maybe backwards compat with some version that had it in a public header?
[15:21:27 CEST] <Daemon404> i dunno, but ffmpeg fixed it anyway in its codebase.
[15:21:31 CEST] <Daemon404> so /care
[15:21:45 CEST] Action: rcombs shrugs
[15:27:45 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:90ed6c5cf7f2: h2645_parse: compute the actual data length, without trailing paddding
[15:27:46 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:79aafd43fd25: Merge commit '90ed6c5cf7f236bc9efb47c97b40358c666d1386'
[16:04:56 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:e481458bc308: h264: factor out pred weight table parsing into a separate file
[16:04:57 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:ee38234c43b6: Merge commit 'e481458bc308ee838deaeacac51929514762e7a7'
[16:22:05 CEST] <cone-104> ffmpeg 03Anton Khirnov 07master:e42ca48a8bdd: svq3: rip out the mb decoding code shared with h264
[16:22:06 CEST] <cone-104> ffmpeg 03Derek Buitenhuis 07master:f8d1bb2f2ce9: Merge commit 'e42ca48a8bddc637a4013ab253598973f07e1a5c'
[16:56:08 CEST] <Angus> hmm, running into an Assert in av_free
[16:56:10 CEST] <Angus> #1  0x00007ffff70e1e8a in __GI_abort () at abort.c:89 #2  0x00007ffff3b3149e in av_free (ptr=<optimized out>) at libavutil/mem.c:233
[16:57:06 CEST] <fritsch> happens and without further info it will continue to happen
[16:57:07 CEST] <durandal_170> more info needed
[16:57:10 CEST] <Angus> the piece of memory is allocated via av_malloc( pBufferCtx->iBufferSize)
[16:57:21 CEST] <Angus> and is part of
[16:57:26 CEST] <Angus> avio_alloc_context(ffBuffer, pBufferCtx->iBufferSize, 			0, pBufferCtx, &read_packet, NULL, NULL);
[16:57:26 CEST] <fritsch> pastebin, please
[16:57:37 CEST] <Angus> pastebin is blocked here :(
[16:57:42 CEST] <fritsch> sprunge.us
[16:57:46 CEST] <fritsch> paste.ubuntu.com
[16:58:01 CEST] <Angus> or not
[16:58:01 CEST] <Angus> http://pastebin.com/49xGuicQ
[16:58:35 CEST] <Angus> stack trace:
[16:58:35 CEST] <Angus> http://pastebin.com/bATZdgbz
[16:59:49 CEST] <Angus> I suspect read_packet might be corrupting the memory, if av_free is behaving correctly
[17:01:04 CEST] <fritsch> how large is iBufferSize ?
[17:01:11 CEST] <jkqxz> Not that it's obviously relevant to your problem, but why do you have MEMALIGN_HACK set?
[17:01:57 CEST] <Angus> I'm not really sure; the ffmpeg make config was given to me by someone
[17:02:04 CEST] <Angus> fritsch: http://pastebin.com/LexzfKkK
[17:02:20 CEST] <Angus> 1206 bytes it seems
[17:03:02 CEST] <fritsch> Angus: increase to 4k
[17:03:04 CEST] <fritsch> or something
[17:03:22 CEST] <Angus> what does memalign-hack do anyway?
[17:04:11 CEST] <jkqxz> Don't do that, it will only confuse things.  You're using glibc, so you have a perfectly good posix_memalign().
[17:04:50 CEST] <Angus> alright, will try this again without the memalign-hack
[17:05:01 CEST] <wm4> Angus: I _think_ you need to alloc the buffer as array
[17:05:27 CEST] <jkqxz> It builds aligned allocation out of unaligned allocation, because some platforms in the stone age didn't support that.
[17:05:34 CEST] <fritsch> wm4: i don't think sop
[17:05:39 CEST] <cone-104> ffmpeg 03Nicolas George 07master:b8fa374fb6eb: lavf/concatdec: remove unrelated change during codecpar merge.
[17:05:40 CEST] <cone-104> ffmpeg 03Nicolas George 07master:0cb19c30c6a1: lavf/concatdec: clear extradata when inserting h264_mp4toannexb bsf.
[17:05:46 CEST] <wm4> I was wrong
[17:06:22 CEST] <fritsch> that buffer is quite small
[17:06:25 CEST] <wm4> IMO this code should just work
[17:06:27 CEST] <fritsch> yes
[17:06:45 CEST] <fritsch> there is nothing wrong I can see, but wasn't there some "minimal" buffer that needs to be used?
[17:06:48 CEST] <fritsch> like 4k?
[17:06:56 CEST] <wm4> keep in mind that libavformat may free the buffer and replace it with another allocation
[17:07:02 CEST] <wm4> (but you still have to free it at the end LOL)
[17:07:50 CEST] <Angus> fritsch, I just tried to compile my code with the buffersize set to 4k, and still crashed on the same line.
[17:08:22 CEST] <fritsch> can you post your read_packet method?
[17:10:37 CEST] <Angus> it's very messy. http://pastebin.com/SRzwHNDw
[17:12:04 CEST] <fritsch> can you just return in that method?
[17:12:07 CEST] <fritsch> for testing?
[17:12:29 CEST] <fritsch> in line 16 i am not sure that >= is what you want there ... but it's basically unreadable :-)
[17:13:19 CEST] <wm4> check with valgrind?
[17:13:30 CEST] Action: fritsch hints for an off by one :-)
[17:13:49 CEST] <fritsch> btw. I highly suggest you clean up that code
[17:13:55 CEST] <fritsch> especially the big if and else
[17:14:18 CEST] <fritsch> i think you get that done with 4 lines when using min / max and offset
[17:14:26 CEST] <Angus> let me check a few things first. Yes, that code will be cleaned once I figure out what's wrong with it.
[17:14:38 CEST] <D`K_C> Hi, is there a way to use ffmpeg to get the raw data of an HLS stream? I mean ffmpeg would fetch the different elements of the playlist and I could read raw data using a xx_read function? I tried to use avio_open but (of course) it simply fetches the playlist and does not assemble the multiple parts
[17:14:55 CEST] <wm4> what do you even mean by "raw"
[17:20:05 CEST] <D`K_C> the playlist is made of ts files, and the application is designed in such a way that it needs to have access to these streams
[17:22:04 CEST] <wm4> define raw data
[17:23:14 CEST] <D`K_C> ts streams
[17:25:10 CEST] <rcombs> D`K_C: use either the HLS protocol (avio_open hls://) or the HLS demuxer (avformat_open_input)
[17:25:35 CEST] <rcombs> the protocol if you actually want the TS files concatenated; the demuxer if you want AVPackets
[17:28:09 CEST] <wm4> if you just want the ts URLs, it's better if you take 5 mins to write a playlist parser
[17:28:43 CEST] <rcombs> ^ yeah
[17:36:11 CEST] <cone-104> ffmpeg 03Rodger Combs 07master:95116bf35f1b: lavc/audiotoolboxdec: fix memory leak
[17:36:12 CEST] <cone-104> ffmpeg 03Rodger Combs 07master:e1c20485c1d4: lavc/audiotoolboxdec: move to new BSF API
[17:37:56 CEST] <D`K_C> okay, I managed to get the TS files using avio_open hls+http://, it was just a quick prototype to test the rest of the application. What would be the advantages of writing a playlist parser over using ffmpeg?
[17:43:02 CEST] <wm4> if it works for you, then fine
[18:11:29 CEST] <durandal_170> anyone against including bonk decoder? 
[19:01:21 CEST] <jamrial> durandal_170: what's bonk?
[19:02:01 CEST] <durandal_170> jamrial: whery old audio lossy/lossless codec
[19:02:27 CEST] <jamrial> i don't see why not, then
[19:08:46 CEST] <wm4> is it the companion of bink?
[19:17:58 CEST] <durandal_170> lol, nope
[19:49:20 CEST] <cone-104> ffmpeg 03Michael Niedermayer 07master:005c61c6b898: avcodec/ttaenc: Reallocate packet if its too small
[20:13:25 CEST] <b_amabo> michealni: I am here because I wish to participate in the next round of Outreachy with FFmpeg. please I need guidance on how I can start contributing in preparation for the program
[20:15:00 CEST] <JEEB> since outreachy is paid by the organizations themselves, it is never sure if FFmpeg will participate in something. to initialize yourself with the project whatever the future might hold one of the best ways is to try and use it and find things that irk you in one way or another
[20:15:15 CEST] <JEEB> then looking into the components and discussing them
[20:15:20 CEST] <JEEB> if you have never compiled FFmpeg, start from there
[20:15:42 CEST] <JEEB> so you get basic FFmpeg binaries built, which are by default static so you are able to run them right away
[20:16:02 CEST] <JEEB> you probably only require git, yasm and basic compilation tools
[20:18:53 CEST] <b_amabo> JEEB: thanks you for the heads up!
[20:21:04 CEST] <kierank> have a look at the tasks for the previous round
[20:25:48 CEST] <b_amabo> kierank: I have gone through the tasks list and I find for creating a fuzzing testsuit for FFmpeg and that for Improving Selftest Coverage intersting to me
[20:29:08 CEST] <kierank> b_amabo: ah I see your email
[20:29:40 CEST] <b_amabo> okay great!
[20:31:30 CEST] <b_amabo> kierank: @JEEB has given me some hints to get started but getting more from you will be a plus
[20:36:31 CEST] <kierank> have a look at the patches for fffuzz on ffmpeg-devel
[20:36:48 CEST] <kierank> and look at https://fuzzing-project.org/
[20:37:23 CEST] <b_amabo> okay I will do that ASAP
[20:53:30 CEST] <Zeranoe> So github has a rather misleading use of "committed on ...". This can be seen here: https://github.com/FFmpeg/FFmpeg/commit/8ff0f6ae8253d394f096b39d69b66e5247ed1066 Github reports "cus committed on Mar 15" yet that's the author date as seen from 'git show -s --format=%ai 8ff0f6a'. The actual committed date (git show -s --format=%ci 8ff0f6a) is '2016-03-26 23:26:27 +0100'
[20:54:13 CEST] <wm4> there's a commit date and an author date
[20:54:39 CEST] <Zeranoe> I know
[20:55:22 CEST] <Zeranoe> GitHub's use of 'committed on Mar 15' would imply it's referring to the committed date, but that's actually the author date
[20:58:09 CEST] <wm4> github being github
[20:58:14 CEST] <Daemon404> Zeranoe, it gets even more confusing when the person who authors is not the smae as the committed
[20:58:20 CEST] <BBB> Daemon404: when are you next in NY again?
[20:58:28 CEST] <Daemon404> it says "First Guy committed with Second Guy on <...>"
[20:58:33 CEST] <Daemon404> BBB, i arrive this sunday
[21:00:55 CEST] <Zeranoe> What a horrible choice of words
[21:01:00 CEST] <Zeranoe> on GitHub.
[21:01:25 CEST] <Shiz> git config user.name 'a stick up his ass'
[21:01:31 CEST] <Shiz> now to send in a patch....
[21:02:08 CEST] <Daemon404> doesnt work
[21:02:18 CEST] <Daemon404> github displays the *github* user name in these sentences
[21:02:21 CEST] <Daemon404> not the, you know, name in git.
[21:02:25 CEST] <wm4> Zeranoe: the worst is that github reorders commits in pull request by author time or so
[21:02:46 CEST] <Daemon404> ... you must be jesting
[21:02:50 CEST] <Zeranoe> wm4: Lovely. That's the last time I use it for info
[21:02:51 CEST] <Daemon404> ive never seen hits behavior
[21:02:58 CEST] <Daemon404> this*
[21:03:09 CEST] <wm4> it's a common complaint
[21:05:54 CEST] <Shiz> Daemon404: a_stick_up_his_ass
[21:05:56 CEST] <Shiz> ez fix
[21:25:03 CEST] <BBB> Daemon404: so, for colorspace, is there a specific reason you asked, i.e. a specific concern?
[21:30:54 CEST] <Daemon404> confusion mostly
[21:31:07 CEST] <Daemon404> and hoping a 2nd swscale would not live in tree in lavfi
[21:36:28 CEST] <BBB> Daemon404: no, no; if it overlaps significantly, Ill merge them and call it swscale
[21:36:33 CEST] <BBB> see wiki/swscale
[21:36:48 CEST] <BBB> thats the eventual goal, but its currently strictly separate
[21:37:30 CEST] <wm4> <Daemon404> and hoping a 2nd swscale would not live in tree in lavfi <- lol
[21:38:38 CEST] <jamrial> we still sorta have an swresample in avcodec :p
[21:38:52 CEST] <wm4> because we never remove anything
[21:38:53 CEST] <jamrial> it should be gone in the next bump, though
[21:39:03 CEST] <wm4> do we still have an deinterlacer in avcodec?
[21:39:03 CEST] <BBB> we had a swscale sorta thing in lavc also
[21:39:12 CEST] <BBB> I believe its gone now
[21:39:15 CEST] <BBB> let me confirm
[21:39:20 CEST] <jamrial> wm4: it's deprecated and already (or about to be) two years old, so next major bump will get rid of it
[21:39:51 CEST] <BBB> I think it was removed in the last bump
[21:39:56 CEST] <BBB> I dont see it anymore
[21:40:39 CEST] <BBB> see 41194f065c8e9b138db069417494e2f845c7b275
[21:40:44 CEST] <BBB> lavc: Drop deprecated deinterlace module
[21:40:50 CEST] <BBB> Date:   Sat Sep 5 17:05:46 2015 +0200
[21:41:17 CEST] <BBB> (or cad40a3833ad81a352e7657ec6f7d637cea3b798, the libav commit that the above merges)
[21:44:49 CEST] <wm4> amazing, so we do remove stuff
[21:46:12 CEST] <wm4> so can we remove the old vdpau decoder
[21:48:27 CEST] <cone-104> ffmpeg 03Michael Niedermayer 07master:4efd3ec50a54: avcodec/svq3: fix assert type (was av_assert2 in h264 from where this was copied)
[22:24:38 CEST] <ubitux> BBB: sierra2_4a is a nice dithering too
[22:24:49 CEST] <ubitux> see palettegen for various dithering coeff
[22:25:45 CEST] <ubitux> sorry i mean paletteuse
[22:31:14 CEST] <BBB> ubitux: so, I have to be honest, I dont really see the difference between all these dithering algos
[22:31:18 CEST] <BBB> I mean, I see that theyre differen
[22:31:27 CEST] <BBB> but I Dont think any one is absolutely better than any other
[22:31:39 CEST] <BBB> FSB is widely documented and easy, so I usually just use that one first
[22:31:42 CEST] <ubitux> depend on the use case i guess yeah
[22:31:53 CEST] <BBB> probably
[22:32:01 CEST] <ubitux> for the 256 color case, it has a huge impact :p
[22:32:01 CEST] <BBB> FSB is already better than what swscale does :-p
[22:32:24 CEST] <ubitux> http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
[22:32:26 CEST] <nevcairiel> error diffusion algorithms like FSB have a few problems with moving images as the dither pattern can change from minimal pixel changes, although its probably only visible in pixel art videos =p
[22:32:32 CEST] <ubitux> BBB: look at the end of the post
[22:32:35 CEST] <ubitux> for the various comparisons
[22:32:53 CEST] <BBB> hm...
[22:32:55 CEST] <BBB> lemmecheck
[22:33:33 CEST] <ubitux> sierra2 requires 3 lines though
[22:34:23 CEST] <ubitux> found most of these from http://www.efg2.com/Lab/Library/ImageProcessing/DHALF.TXT
[22:34:54 CEST] <BBB> yeah, sierra2 and related algos use 12 neighbours instead of 4
[22:34:57 CEST] <BBB> thats why theyre slower, I think
[22:35:03 CEST] <BBB> (4 = fsb)
[22:37:42 CEST] <nevcairiel> fsb's biggest problem is that SIMDing it is really hard
[22:37:56 CEST] <ubitux> like all the other actually
[22:38:22 CEST] <nevcairiel> thats why i like ordered or random dither, quality is still ok for images (your palette case may be different), and its super easy to code
[22:38:46 CEST] <BBB> Im going to try to code a semi-simd layer
[22:38:51 CEST] <BBB> I believe it should be relatively fast
[22:38:55 CEST] <BBB> and compared to video coding, its trivial
[22:39:10 CEST] <BBB> so for 10/12bit sources of high value, the cost of encoding is still much higher than the cost of dithering
[22:39:12 CEST] <BBB> and then its all ok
[00:00:00 CEST] --- Wed Apr 27 2016