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

[burek]

[00:27:34 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:3cb85ad4450b: tests/fate-run: Pass bitexact flags to enc_dec_pcm() output
[00:53:14 CEST] <BBB> durandal_170: I mean, one muxer for each configuration is a little much, it should just be a flag or something, no?
[01:36:01 CEST] <RiCON> http://j.fsbn.eu/4HU0.txt casualty of api changes?
[01:41:51 CEST] <BBB> RiCON: AVPixelFormat
[01:43:00 CEST] <RiCON> ffms2 too
[02:43:50 CEST] <RiCON> just changing PixelFormat to AVPixelFormat did fix it
[03:25:10 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:61009a709c76: tests/fate: replace all -f md5 by framemd5
[11:04:21 CEST] <cone-970> ffmpeg 03Zhang Rui 07master:929451c5cba5: avformat/async: replace strerror with av_err2str
[12:10:10 CEST] <cone-970> ffmpeg 03Ganesh Ajjanagadde 07master:d74123d03eb1: avfilter/af_asyncts: use llabs for int64_t
[12:33:02 CEST] <cone-970> ffmpeg 03Clément BSsch 07master:d9464e9c14f4: doc/examples/demuxing_decoding: simplify api_mode to refcount
[12:58:21 CEST] <kierank> atomnuker: https://www.youtube.com/watch?v=a52ZSCIAoRk
[13:00:42 CEST] <atomnuker> that's clever, using loops of wires to detect position
[13:01:55 CEST] <atomnuker> If I were making a train positioning system I'd abuse the power rail and send data over small fluctuations
[13:02:30 CEST] <atomnuker> the DLR is overground only so no problem with GPS
[13:02:38 CEST] <kierank> not all
[13:02:56 CEST] <kierank> the bit to bank and the bit to stratford international
[13:02:58 CEST] <kierank> and probably others
[13:03:38 CEST] <atomnuker> I'd probably use TCP to prevent packet errors
[13:04:25 CEST] <atomnuker> and if you transmit train position like every 15 seconds you'd probably be good for about 40 trains on the same power line
[13:04:55 CEST] <atomnuker> problem is those signals could travel up the main transformers into the power line and piss off the power provider big time
[13:05:23 CEST] <atomnuker> (though they don't seem to care about bridge rectifiers in crap LED lights directly on the mains kicking up a ton of EMI)
[13:09:41 CEST] <iive> i'm not quite sure you want to go near power rail... that thing is holding way too much power
[13:10:06 CEST] <atomnuker> nah, the DLR has protected rails
[13:10:14 CEST] <atomnuker> there's a cover all the way around it
[13:10:22 CEST] <atomnuker> and it's elevated
[13:10:38 CEST] <atomnuker> so you can walk over it as long as you don't touch the underside
[13:11:03 CEST] <atomnuker> even the tube's 4 rail system is kinda safe too
[13:11:14 CEST] <atomnuker> the inner rail carries only -235 or so volts
[13:11:38 CEST] <atomnuker> so you'd get a shock if you touch any of the 2 ground rails but you won't die
[13:11:48 CEST] <atomnuker> well, depends on how you touch it
[13:11:56 CEST] <atomnuker> if you grip it you're a goner
[13:12:16 CEST] <atomnuker> since all/most rail power systems run on DC
[13:16:32 CEST] <iive> my point is... you don't want low power electronics anywhere near high power electronics.
[13:21:44 CEST] <atomnuker> you can easily modulate pulses onto a high voltage DC line
[13:22:34 CEST] <atomnuker> optoisolators between your logic board and your high voltage board basically eliminates all danger to the main electronics
[13:23:39 CEST] <atomnuker> and as for how to insert the pulses onto the line, you can just use some silicone controlled rectifiers
[13:24:31 CEST] <atomnuker> they make those things monster-size too, since they're used in HVDC international transmissions
[13:38:52 CEST] <cone-970> ffmpeg 03Yayoi 07master:50332f8a6bc3: avcodec/srtdec: factor out HTML parsing code
[13:38:53 CEST] <cone-970> ffmpeg 03Yayoi 07master:fc9aa1fb4694: fate/subtitles: add a new test for SAMI demuxer and decoder
[13:38:54 CEST] <cone-970> ffmpeg 03Yayoi 07master:1bb8a53f080e: avformat/samidec: do not include trailing sami footer in the last packet
[13:38:55 CEST] <cone-970> ffmpeg 03Yayoi 07master:87f90be4f2a6: avcodec/samidec: use ff_htmlmarkup_to_ass()
[13:38:56 CEST] <cone-970> ffmpeg 03Clément BSsch 07master:26786f43d7d5: avcodec/htmlsubtitles: drop avcodec dependency
[14:04:07 CEST] <cone-970> ffmpeg 03Clément BSsch 07master:db18b3d6e6fa: avcodec/samidec: small indent fix
[14:04:40 CEST] <michaelni> nevcairiel, as you do the merges nowadays you should have op 
[14:10:31 CEST] <nevcairiel> i thought i had
[14:17:24 CEST] <michaelni> i thought too but seems you didnt
[15:29:21 CEST] <cone-970> ffmpeg 03Clément BSsch 07master:a388ca359d78: avfilter/sine: support expression in the number of output samples
[15:31:03 CEST] <ubitux> kierank: if you have a chance to try this (^) out along with your testsrc chain thing, that would be welcome
[15:31:11 CEST] <ubitux> hopefully the example in the doc is correct
[15:33:24 CEST] <kierank> I will look at work
[15:33:29 CEST] <kierank> But thanks
[15:46:32 CEST] <cone-970> ffmpeg 03Rodger Combs 07master:d2d020bb3254: avcodec/htmlsubtitles: handle leading whitespace before tag names
[15:49:08 CEST] <cone-970> ffmpeg 03Rostislav Pehlivanov 07release/2.8:7e853879cedd: fate: increase the fuzz of the AAC encoder aref test
[15:49:09 CEST] <cone-970> ffmpeg 03Zhang Rui 07release/2.8:8cd24f8fe7b8: avformat/async: replace strerror with av_err2str
[15:49:10 CEST] <cone-970> ffmpeg 03Ganesh Ajjanagadde 07release/2.8:aa661d3672a6: avfilter/af_asyncts: use llabs for int64_t
[15:59:39 CEST] <cone-970> ffmpeg 03Michael Niedermayer 07release/2.8:48211b0c0dfc: set version to 2.8
[16:11:31 CEST] <cone-970> ffmpeg 03Michael Niedermayer 07master:c5406d5e1503: Changelog: add 2.8
[16:11:33 CEST] <cone-970> ffmpeg 03Michael Niedermayer 07release/2.8:90d29c3d048f: Changelog: Add 2.8
[16:25:07 CEST] <atomnuker> michaelni: okay if I push a few commits or do you still have business with 2.8 & the repo?
[16:26:56 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:eb011f73ca2f: avcodec/alac: remove dead code cruft
[16:26:57 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:2cad7eebc13f: avcodec/flac: remove avpriv parsing API cruft
[16:26:58 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:34e85cb34067: avcodec/vorbis: remove avpriv vorbis parser cruft
[16:31:32 CEST] <atomnuker> well I guess it's ok
[16:31:42 CEST] <cone-970> ffmpeg 03Rostislav Pehlivanov 07master:92aa3e7fb21a: aacenc: copy PRNG from the decoder
[16:31:43 CEST] <cone-970> ffmpeg 03Rostislav Pehlivanov 07master:b9b1fd118347: aaccoder: use roundf() instead of ceilf()
[16:31:44 CEST] <cone-970> ffmpeg 03Rostislav Pehlivanov 07master:a71f7de95bf3: aacenc_is: ignore PNS band types
[16:31:45 CEST] <cone-970> ffmpeg 03Rostislav Pehlivanov 07master:8848c8440eb5: aacenc_pred: disable PNS SFBs and disable right predictors with IS
[16:31:46 CEST] <cone-970> ffmpeg 03Rostislav Pehlivanov 07master:033e58941e68: aaccoder: rewrite PNS implementation
[16:31:47 CEST] <cone-970> ffmpeg 03Rostislav Pehlivanov 07master:ff99a3885574: fate: adjust AAC encoder tests values
[16:33:08 CEST] <atomnuker> fair warning, the new PNS implementation increases quality by a lot
[16:36:11 CEST] <ubitux> yay
[16:36:17 CEST] <ubitux> is there more incoming large improvements?
[16:37:08 CEST] <ubitux> i know the question raises often, but does the aac encoder still need the experimental flag?
[16:37:28 CEST] <nevcairiel> I think the plan was to remove it once Claudio's changes are ib
[16:37:32 CEST] <nevcairiel> in
[16:37:37 CEST] <kierank> we should maybe also fuzz the encoder
[16:37:53 CEST] <kierank> fdk used to crash quite a bit
[16:37:57 CEST] <ubitux> btw, the enable/disable opt flags shouldn't be required
[16:38:14 CEST] <nevcairiel> Encoders are hard to break, since they don't read a bitstream
[16:38:26 CEST] <ubitux> which reminds me i need to add the av opt bool to make automatic aliases..
[16:38:50 CEST] <kierank> nevcairiel: that's what I thought until some jingle at 1 oclock every day on hbo asia used to crash fdk
[16:39:37 CEST] <nevcairiel> The aac encoder asserts on some bitstream, but I think there was a fix for that in the works
[16:40:21 CEST] <atomnuker> ubitux: there's always large improvements coming, I'm rewriting big chunks every few days or so
[16:40:32 CEST] <ubitux> nice :)
[16:40:53 CEST] <atomnuker> nevcairiel: yes, the asserts will be gone with Claudio's commits since he rewrote the whole coder
[16:50:05 CEST] <atomnuker> ubitux: what's wrong with having a few options to turn tools on or off?
[16:50:18 CEST] <ubitux> atomnuker: i meant the constant themselves
[16:50:28 CEST] <ubitux> they are way too generic not to be handled at avopt level
[16:50:49 CEST] <ubitux> you should just have an AV_OPT_TYPE_BOOL that recognises 0/1/true/false/enable/disable/yes/no..
[16:51:37 CEST] <ubitux> avopt already recognizes stuff like "none"
[16:51:49 CEST] <ubitux> but yeah we need a proper opt bool
[16:51:53 CEST] <ubitux> i'll check that
[16:52:32 CEST] <ubitux> anyway, currently we use 0/1 with opt type int for those
[17:35:29 CEST] <ubitux> ok almost done adding opt bool
[17:56:00 CEST] <ubitux> > Setting entry with key 'duration' to value '0:00:00.001000'
[17:56:02 CEST] <ubitux> weird.
[17:56:14 CEST] <ubitux> (duration with default .i64=1000)
[17:56:20 CEST] <ubitux> (not a string)
[17:57:08 CEST] <durandal_170> in milliseconds
[17:57:19 CEST] <durandal_170> Or?
[17:58:01 CEST] <ubitux> dunno, it looks kinda strange
[17:58:05 CEST] <ubitux> maybe that's normal
[19:16:43 CEST] <ubitux> ok, bool done
[19:17:01 CEST] <ubitux> does anyone have in mind where the av opt bool could be used so i can test it in real cases?
[19:17:09 CEST] <ubitux> i just added it to kerndeint and dshow
[19:17:24 CEST] <ubitux> i'm looking for case where there is also a third boolean case (that is: "auto")
[19:17:27 CEST] <ubitux> +s
[19:17:41 CEST] <ubitux> (aac enc is another place i'll patch)
[19:25:20 CEST] <durandal_170> see dynaudnorm, three occurences
[19:26:30 CEST] <ubitux> thx
[19:34:01 CEST] <ubitux>   -aac_pns           <boolean>    E...A... Perceptual Noise Substitution (default true)
[19:34:03 CEST] <ubitux>   -aac_is            <boolean>    E...A... Intensity stereo coding (default true)
[19:34:05 CEST] <ubitux>   -aac_tns           <boolean>    E...A... Temporal noise shaping (default false)
[19:34:07 CEST] <ubitux>   -aac_pred          <boolean>    E...A... AAC-Main prediction (default false)
[19:34:09 CEST] <ubitux> yeah kinda better than way
[19:40:47 CEST] <cone-098> ffmpeg 03Rostislav Pehlivanov 07master:1956cfbaedd3: aacenc_is: take absolute coefficient value upon energy calculations
[19:41:29 CEST] <atomnuker> ubitux: yeah, looks better
[20:40:18 CEST] <ubitux> Ganesh doesn't have write permissions?
[20:51:45 CEST] <BBB> ubitux: tnx, I was wondering why we didnt have that
[20:51:54 CEST] <BBB> (I just assumed there was a reason and stopped caring)
[20:52:41 CEST] <cone-098> ffmpeg 03Michael Niedermayer 07master:7990beedee02: avformat/http: require seekability only when seeking to position != 0
[20:52:42 CEST] <cone-098> ffmpeg 03Michael Niedermayer 07master:63974bd494c6: avformat/http: print error that causes reconnection
[21:07:42 CEST] <cone-098> ffmpeg 03Ronald S. Bultje 07master:a02e27c03d3c: md5: change flags to match framemd5.
[21:07:43 CEST] <cone-098> ffmpeg 03Ronald S. Bultje 07master:f12093fffdae: vp9: fix integer overflows in sse2 version of iadst4.
[21:07:44 CEST] <cone-098> ffmpeg 03Ronald S. Bultje 07master:e855ed17a722: Update md5 muxer docs to indicate that it ignores timestamps.
[21:12:17 CEST] <ubitux> BBB: the reason was probably that it's a pain to follow the complexity of avopt
[21:12:26 CEST] <ubitux> i actually tried to do that once a while ago
[21:12:53 CEST] <ubitux> but yeah otherwise no special reason
[21:13:01 CEST] <ubitux> that code is actually pretty well tested
[21:13:13 CEST] <ubitux> (and easy to test)
[22:38:35 CEST] <microchip_> why are c->a_mode and c->num_channel both set to 9 for 5.0/5.1 audio in dcaenc.c ? 
[22:50:04 CEST] <microchip_> this surely is incorrect, no?
[22:50:08 CEST] <microchip_> case AV_CH_LAYOUT_5POINT1:      c->a_mode = 9; c->num_channel = 9; break;
[22:50:51 CEST] <BtbN> depends on what a_mode and num_channel expects.
[22:52:28 CEST] <microchip_> BtbN: if i do something like: -c:a:0 dca -b:a:0 1059k -ac:a:0 6 then ffmpeg errors out with DCA saying 5.1 channels not supported. But if I use -ac:a:0 9, then encoding works and uses 5.1 dca channels
[22:53:03 CEST] <microchip_> 1509k i mean
[00:00:00 CEST] --- Mon Sep  7 2015