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

[burek]

[00:31:22 CET] <cone-337> ffmpeg 03Marton Balint 07master:d25769555bb3: avutil/frame: fix av_frame_copy for unknown layouts
[02:14:03 CET] <cone-337> ffmpeg 03Andreas Cadhalpun 07master:3d673078a03a: ircamdec: prevent overflow during block alignment calculation
[09:04:18 CET] <cone-044> ffmpeg 03Tobias Rapp 07master:e65db4ce5966: avformat/avienc: add reserve_index_space option
[10:03:31 CET] <wm4> does vp8 have invisible frames or whatever they're called?
[10:06:29 CET] <wm4> seems very much like "no"
[10:07:28 CET] <wm4> so I have no idea how a vp8 stream could have "|  + Reference block: -0.000000ms" (with vp9 it probably could be, in a brokenish way, althiugh I think vp9 packs invisible frames with visible frames into 1 packet)
[10:10:07 CET] <nevcairiel> i think vp8 also had invisible frames
[10:15:16 CET] <wm4> they must have been "different"
[10:26:49 CET] <jkqxz> VP8 does have invisible frames.
[10:27:41 CET] <jkqxz> It just doesn't have the infrastructure around them to do useful things like VP9 does.  So, no superframe packing, and if you want to show an invisible frame later you have to code a whole all-skip frame.
[10:29:22 CET] <wm4> slightly related, we were trying to figure out how Mozilla could show alpha webms, even though it uses ffvp9 - well...: https://hg.mozilla.org/mozilla-central/rev/ffe69d7de0a8
[10:30:37 CET] <nevcairiel>  the answer is, they dont use ffvp9? =P
[10:34:38 CET] <durandal_170> does anyone have samples with hdmv bluray text subtitles?
[10:34:59 CET] <JEEB> I think the libbluray guy was working on that a few years back
[10:35:08 CET] <JEEB> so poking #videolan probably will come up with samples
[10:37:41 CET] <nevcairiel> they are so rare that  i never actually had any disc with them
[10:39:06 CET] <JEEB> yeah, they are
[10:39:11 CET] <JEEB> they're in the spec but welp
[10:45:36 CET] <cone-044> ffmpeg 03Moritz Barsnick 07master:0478728db02d: lavf/xwma: fix incorrect format specifier
[10:49:44 CET] <cone-044> ffmpeg 03Carl Eugen Hoyos 07master:12f7c091e804: lavc/alac: Export samplerate.
[11:00:47 CET] <ubitux> ok so
[11:00:52 CET] <ubitux> looking at the next hevc merges
[11:01:10 CET] <ubitux> it appears libav decided to rename almost all the callbacks
[11:01:24 CET] <ubitux> transform_add became add_residual
[11:01:25 CET] <wm4> yay
[11:01:42 CET] <ubitux> idct_4x4_luma became transform_4x4_luma
[11:02:07 CET] <ubitux> transform_skip became mmmh... maybe dequant, not sure
[11:02:22 CET] <ubitux> should we use their naming?
[11:02:26 CET] <nevcairiel> sometimes i think they do that on purpose just to be different
[11:03:21 CET] <nevcairiel> in the long run it might be easier to use their names
[11:03:31 CET] <ubitux> ok, i'll do the switch then
[11:04:28 CET] <ubitux> i'll probably make a separated commit for the rename though
[11:37:30 CET] Action: ubitux is the rename master
[11:58:43 CET] <cone-044> ffmpeg 03Paul B Mahol 07master:3405d6c7bc06: avfilter/overlay: add gbrp output format
[13:07:48 CET] <Chloe> ubitux: yes, I complained a bit about that 
[13:08:59 CET] <ubitux> the common rationale is "why should we make our codebase worse because of ffmpeg?"
[13:09:09 CET] <ubitux> there is nothing we can complain about, we'll have to deal with it
[13:09:28 CET] <ubitux> they're not doing themselves a service but that's not our problem
[13:10:00 CET] <JEEB> (´4@)
[13:10:05 CET] <JEEB> I did like the cropping change tho
[13:10:06 CET] <Chloe> Considering they happily took in ffmpeg code when I put it on a silver platter... 
[13:10:17 CET] <JEEB> yes, they just don't actively backport
[13:10:45 CET] <Chloe> (although this still wasn't good enough, so I gave up and let them do whatever since they didn't listen at all) 
[13:11:39 CET] <ubitux> after years of trying i can safely say there is nothing we can do, better make yourself a reason
[13:16:44 CET] <Chloe> What's stopping a reunification of libav and ffmpeg?
[13:17:36 CET] <wm4> <JEEB> I did like the cropping change tho <- is that somehow incompatible to ffmpeg?
[13:22:41 CET] <ubitux> Chloe: everything and nothing
[13:26:20 CET] <Chloe> Nothing ever gets sorted out :(
[13:26:49 CET] <Compn> why dont redhat and debian merge? why dont apple and microsoft merge?
[13:26:53 CET] <Compn> why dont open bsd and freebsd merge ?
[13:26:58 CET] <Compn> the questions you seek cannot be answered
[13:27:01 CET] <Compn> move on
[13:27:43 CET] <wm4> is it apple which regularly merges all code from microsoft, or the other way around?
[13:27:53 CET] <ubitux> :D
[13:28:02 CET] <Compn> microsoft is the one that takes apple features , yes
[13:28:14 CET] <Compn> didnt you see bill gates documentary from the 90s ?
[13:28:33 CET] <Compn> pirates of silicon valley i think
[13:29:09 CET] <Compn> s/documentary/tvmovie
[13:30:01 CET] <Compn> also move on.
[13:33:09 CET] <Chloe> Maybe I'll understand it when I'm old and angry, but for now it just seems stupid. 
[13:33:56 CET] <nevcairiel> stupidity doesnt usually stop people from doing things =p
[13:34:00 CET] <wm4> basically a few years ago people hated each other's guts
[13:34:21 CET] <wm4> and then the flame wars escalated
[13:34:26 CET] <wm4> or something
[13:34:51 CET] <nevcairiel> doesnt help that some people are left on either side that still carry an irrational hate
[13:34:52 CET] <Compn> Chloe : welcome to the real world. the real world is stupid
[13:35:24 CET] <ubitux> nevcairiel: stupidity can even be a motivator
[13:57:25 CET] <durandal_170> ubitux: how to handle hdmv text subtitles, their pts and duration are stored in packet itself
[13:58:09 CET] <ubitux> isn't it an offsetting relative to the packet pts?
[13:58:17 CET] <ubitux> i guess it's just like dvdsub
[13:58:28 CET] <ubitux> pkt_timebase is your friend
[13:58:50 CET] <wm4> something between demuxer and decoder could change the timestamps
[13:58:54 CET] <wm4> you better respect that
[14:38:37 CET] <durandal_170> ubitux: its absolute. 
[14:39:11 CET] <ubitux> then use pkt_timebase to rescale and adjust the timings
[14:43:35 CET] <durandal_170> ubitux: i wrote parser but duration is ignored
[14:44:29 CET] <ubitux> honestly i don't know more, bitmap broadcasting formats are insane and it's a pita. all i know is that they all have double timing, and they use pkt_timebase to rescale all around
[14:44:39 CET] <ubitux> i don't remember the details, all i know is that it's nasty
[14:45:27 CET] <ubitux> we still haven't figure out how to mux dvd subs in "vobsub" properly
[14:46:13 CET] <ubitux> i should work on subtitles currently, but merges became too urgent for me to live peacefully in my head
[14:52:13 CET] <durandal_170> ubitux: this is text subtitle
[14:52:24 CET] <durandal_170> not bitmap
[14:53:30 CET] <ubitux> sorry i just re-read; you're saying pts and duration are at pkt level, so what's the problem?
[14:54:01 CET] <ubitux> i never had the need for a parser so far, it might be broken
[14:56:21 CET] <durandal_170> ubitux: i read pts and duration of subtitle from packet in parser
[14:56:54 CET] <durandal_170> but output srt have 0 duration always
[14:57:16 CET] <wm4> durandal_170: you need to do something like the closed captions thing
[14:57:18 CET] <wm4> and it's terrible
[14:58:02 CET] <ubitux> durandal_170: maybe a bug, we have almost no parser and they're likely badly tested
[15:09:12 CET] <cone-044> ffmpeg 03Tobias Rapp 07master:c778a9657dc8: doc/muxers: add AVI muxer documentation
[15:10:50 CET] <wm4> is that DogFilm file DRMed or so?
[15:12:56 CET] <wm4> lol someone explicitly asking for a libav feature to be merged
[15:23:15 CET] <jkqxz> Huh, that was quick.   It was only pushed late yesterday.
[15:25:07 CET] <wm4> maybe someone really wants it
[15:25:18 CET] <wm4> you should offer porting it to ffmpeg now for money
[15:25:55 CET] <jkqxz> Also they should read the thread and realise that it's basically completely useless without the Intel driver update which hasn't yet landed.  1080p at max quantisation with the current driver is like 6Mbps.
[15:25:58 CET] <ubitux> i should be done with the next merge commit soon, just trying arm compilation
[15:26:10 CET] <ubitux> i hope it won't break mips, poke me if it does
[15:26:12 CET] <wm4> (half-joking, half making fun of anyone who wants to use vp8)
[15:29:56 CET] <mateo`> The Android hw encoders are shit or at least what the MediaCodec API let you do with them. The output quality is so low you have to raise the avg bitrate to 40M to have something ok-ish with complex scenes/images
[15:31:08 CET] <ubitux> note: with a source at around 16M
[15:31:28 CET] <mateo`> I'm so fed up with this crap seriously
[15:32:16 CET] <wm4> mateo`: desktop hw encoders are becoming somewhat close to "ok" only now
[15:37:22 CET] <mateo`> wm4: :(
[15:39:47 CET] <cone-044> ffmpeg 03Alexandra Hájková 07master:1bd890ad173d: hevc: Separate adding residual to prediction from IDCT
[15:39:48 CET] <cone-044> ffmpeg 03Clément BSsch 07master:d0e132bab680: Merge commit '1bd890ad173d79e7906c5e1d06bf0a06cca4519d'
[15:56:16 CET] <ubitux> maybe i should have batch merged those
[16:05:26 CET] <cone-044> ffmpeg 03Mickaël Raulet 07master:4f247de3b797: hevcdsp_template: Templatize IDCT
[16:05:27 CET] <cone-044> ffmpeg 03Mickaël Raulet 07master:a92fd8a06256: hevc: Add DC IDCT
[16:05:28 CET] <cone-044> ffmpeg 03Mickaël Raulet 07master:cc16da75c2f9: hevc: Add coefficient limiting to speed up IDCT
[16:05:29 CET] <cone-044> ffmpeg 03Clément BSsch 07master:2456efcc0fe2: Merge commit '4f247de3b797cdc9d243d26534412f81c306e5b5'
[16:05:30 CET] <cone-044> ffmpeg 03Clément BSsch 07master:a604115f72ad: Merge commit 'a92fd8a06256e71a0be87b03751ec3c2a4a8aa21'
[16:05:31 CET] <cone-044> ffmpeg 03Clément BSsch 07master:05018c2cdaf3: Merge commit 'cc16da75c2f99d92f7a6461100f041352deb6d88'
[16:19:16 CET] <ubitux> oh ffs adding _ randomly in symbols
[16:19:52 CET] <ubitux> asm somehow differs
[16:20:30 CET] <ubitux> jamrial: in fca3c3b61952aacc45e9ca54d86a762946c21942, first function, they moved some mova after the coeffq increment
[16:20:40 CET] <ubitux> opinions on this? mind to benchmark? (/me lazy)
[16:23:02 CET] <durandal_170> what  about gsoc idea: write simd for bunch of lavfi filters?
[16:27:32 CET] <jamrial> ubitux: apply that change
[16:27:38 CET] <jamrial> Gramner suggested it on libav ml
[16:28:30 CET] <jamrial> it makes the intructions smaller after assembly
[16:32:08 CET] <ubitux> ok
[16:32:15 CET] <ubitux> what about the "SECTION" in lowercase?
[16:32:31 CET] <ubitux> it's SECTION almost everywhere, but somehow they changed that one to "section"
[16:32:40 CET] <ubitux> (it's almost everywhere SECTION even in libav)
[16:34:39 CET] <wm4> durandal_170: wouldn't be a bad idea I guess?
[16:34:39 CET] <Gramner> SECTION vs section is purely cosmetical, but maintaining consistency is as always ideal
[16:35:01 CET] <ubitux> i wanted to understand why they decided to change it to lowercase
[16:35:06 CET] <durandal_170> wm4: why?
[16:35:12 CET] <ubitux> making it inconsistent with everything
[16:35:16 CET] <ubitux> last question on that asm
[16:35:19 CET] <ubitux> the tmp suffix changed
[16:35:24 CET] <ubitux> from q and w to d
[16:35:37 CET] <ubitux> should i integrate that change?
[16:36:10 CET] <jamrial> yeah, it makes no difference. better keep the diff as small as possible
[16:36:27 CET] <ubitux> alright
[16:36:38 CET] <ubitux> i'll keep SECTION in uppercase though
[16:38:20 CET] <Gramner> generally using dwords on x86 is recommended if size doesn't matter due to dword being the default operand size in most cases and using anything else requires an additional prefix to be encoded
[16:41:06 CET] <wm4> durandal_170: did you skip a negation?
[16:54:35 CET] <cone-044> ffmpeg 03James Almer 07master:fca3c3b61952: hevc: Add AVX2 DC IDCT
[16:54:36 CET] <cone-044> ffmpeg 03Clément BSsch 07master:78d16eb45217: Merge commit 'fca3c3b61952aacc45e9ca54d86a762946c21942'
[17:04:07 CET] <cone-044> ffmpeg 03Hendrik Leppkes 07master:1ecb63cd1c1a: hevc: set profile based on the profile compatibility flags if needed
[17:04:08 CET] <cone-044> ffmpeg 03Clément BSsch 07master:bd370738baf8: Merge commit '1ecb63cd1c1a4ddc5efed4abbc3158b969d8c5e4'
[17:04:09 CET] <cone-044> ffmpeg 03Clément BSsch 07master:7c300a8ed4ef: lavc/hevc: remove a few random spaces to reduce diff with libav
[17:05:56 CET] <cone-044> ffmpeg 03Hendrik Leppkes 07master:da917fcf5183: avconv_dxva2: add a profile check for hevc
[17:05:57 CET] <cone-044> ffmpeg 03Clément BSsch 07master:dc0ca508ea25: Merge commit 'da917fcf5183ed249ad1285b8edd330f421376c4'
[17:10:31 CET] <cone-044> ffmpeg 03Anton Khirnov 07master:1f7b4f9abc6b: h264dec: make sure not to call finish_setup() more than once per frame
[17:10:32 CET] <cone-044> ffmpeg 03Clément BSsch 07master:5f633c39cd3e: Merge commit '1f7b4f9abc6bae94e576e710b8d10117ca3c8238'
[17:24:53 CET] <cone-044> ffmpeg 03Anton Khirnov 07master:76f7e70aa04f: h264dec: handle zero-sized NAL units in get_last_needed_nal()
[17:24:54 CET] <cone-044> ffmpeg 03Clément BSsch 07master:4039076dc39a: Merge commit '76f7e70aa04fc5dbef5242b11cbf8fe4499f61d4'
[17:25:49 CET] <cone-044> ffmpeg 03Anton Khirnov 07master:e344e65109f1: h264dec: do not call finish_setup() if we have not started a frame
[17:25:50 CET] <cone-044> ffmpeg 03Clément BSsch 07master:fa0276588629: Merge commit 'e344e65109f1a75ca82aff4cecec44e79197753c'
[17:29:57 CET] <cone-044> ffmpeg 03Vittorio Giovara 07master:5d0f85f1b246: libdc1394: Fill in packet data directly
[17:29:58 CET] <cone-044> ffmpeg 03Clément BSsch 07master:b9292a969837: Merge commit '5d0f85f1b2469b60d0838330aabe5353fdd9ef1d'
[17:31:14 CET] <cone-044> ffmpeg 03Vittorio Giovara 07master:0e0538aefc75: avprobe: Zero the allocated avio buffer memory
[17:31:15 CET] <cone-044> ffmpeg 03Clément BSsch 07master:591cf8aa0ee9: Merge commit '0e0538aefc75958ded49f5d075c99a81cf6b2bbb'
[17:35:54 CET] <cone-044> ffmpeg 03Vittorio Giovara 07master:9833a406d3d7: examples: Properly free AVCodecContext
[17:35:55 CET] <cone-044> ffmpeg 03Clément BSsch 07master:126e96533f45: Merge commit '9833a406d3d743d238e4cbee08ffcaa12e067dd2'
[17:36:05 CET] <ubitux> i'm going away soon
[17:36:18 CET] <ubitux> anyone wants to do the x86 batch?
[17:36:58 CET] <ubitux> it shouldn't be too hard, it's code shuffling
[17:37:22 CET] <ubitux> otherwise i'll look at it again tonight or tomorrow
[17:38:10 CET] <jamrial> ubitux: i'll do some
[17:38:18 CET] <ubitux> thanks, hf :)
[17:38:41 CET] <jamrial> no prob :p
[17:38:50 CET] <ubitux> i'll spend the whole day on the merge tmr
[17:39:15 CET] <ubitux> and likely the rest of the week
[17:39:31 CET] <ubitux> ETA: 857 commits
[17:40:51 CET] <jamrial> a lot of those are a conversion to the new bitstream reader
[17:40:59 CET] <jamrial> unlike with codecpar and such, they did one commit per codec
[17:41:09 CET] <ubitux> which is a good thing
[17:41:11 CET] <jamrial> so the commit amount count is pretty bloated, heh
[17:41:30 CET] <ubitux> careful, sometimes there is a nasty blocker waiting around the corner
[17:52:45 CET] <nevcairiel> it took quite some trolling to get them to  split it like that =p
[17:58:19 CET] <BBB> I dont necessarily understand the new bitstream reader
[17:58:27 CET] <BBB> I saw quite some comments on it (I commented once myself)
[17:58:42 CET] <BBB> but if you include variance etc., its not actually faster
[17:58:45 CET] <BBB> often, its slower
[17:58:49 CET] <BBB> why was it pushed through?
[17:59:12 CET] <nevcairiel> because it was sponsored work and it looks pretty
[17:59:17 CET] <atomnuker> nih
[17:59:18 CET] <BBB> (Im not asking to reject the merge or re-do the discussion, merging is probably fine from a code maintenance point of view, I just dont understand what libav is trying to accomplish with this work)
[17:59:24 CET] <nevcairiel> couldnt as well turn down the sponsor money!
[17:59:48 CET] <nevcairiel> also, it was basically done before it was even publicly shown or discussed
[17:59:59 CET] <nevcairiel> because they are into closed-doors work now
[18:00:02 CET] <BBB> I think I gave some technical comments on why it was probably slower
[18:00:06 CET] <BBB> but I was basically told to go away
[18:00:17 CET] <BBB> and then I basically just went away
[18:00:29 CET] <nevcairiel> its faster on some high bitrate codecs like lossless video codecs
[18:00:30 CET] <BBB> I dont understand that attitude :-/
[18:00:36 CET] <nevcairiel> but often slower on light things like audio
[18:00:38 CET] <BBB> its faster on 64bit only
[18:00:42 CET] <BBB> its slower on 32bit
[18:00:48 CET] <nevcairiel> of course, because it uses a 64-bit cache
[18:00:50 CET] <BBB> thats important because a lot of products - even today - are 32bit
[18:00:52 CET] <BBB> exactly
[18:00:57 CET] <BBB> thats what I told them
[18:01:00 CET] <BBB> and they told me to go away
[18:01:14 CET] <BBB> its not hard to make the cache 32bit if the native size is 32bit
[18:01:21 CET] <BBB> but its easier to tell me to go away
[18:01:59 CET] <nevcairiel> but it would make the code more ugly!
[18:02:02 CET] <BBB> and the part where its slower on non-lossless/intraonly codecs is interesting and suggests some operations are not well optimized or generate longer opcodes or so
[18:02:07 CET] <ubitux> maybe that made the code even slower?
[18:02:19 CET] <ubitux> (changing the cache size)
[18:02:26 CET] <nevcairiel> the way this entire thing was handled from day 1 was terrible from their side
[18:02:34 CET] <BBB> maybe, its hard to know because they dont approach this scientifically
[18:02:48 CET] <nevcairiel> developing it without any public interaction and presenting a basically finished huge-ass patch, and refusing to accept any feedback
[18:02:49 CET] <BBB> a scientific approach is heres a commit to change function names"
[18:02:57 CET] <BBB> heres a commit to deinline GET_CACHE etc."
[18:03:02 CET] <BBB> heres a commit to make cache 64bit"
[18:03:07 CET] <BBB> and then have performance implications at each step
[18:03:16 CET] <BBB> evne if its only for a small selection of representative decoders
[18:03:25 CET] <BBB> ohwell
[18:03:27 CET] <BBB> sorry for the rant
[18:03:38 CET] <BBB> I dont think theres a point to any of my stuff other than it being a rant
[18:04:31 CET] <atomnuker> I agree, we should replace the internals of get_bits after we benchmark it ourselves and maybe adjust the cache size via an #include
[18:05:47 CET] <BBB> I wasnt suggesting we go that far, I dont want to slow down the merging or anything
[18:06:01 CET] <BBB> I was just ranting at the process used @ libav and the lack of respectful handling of technical feedback
[18:06:05 CET] <BBB> (for political reasons)
[18:06:14 CET] <nevcairiel> for the merging, all we need is to merge the new API, how its internally implemented is irrelevant for that
[18:06:25 CET] <BBB> thats true
[18:06:26 CET] <nevcairiel> if you want to change it to be better then theirs, go right ahead :D
[18:06:29 CET] <atomnuker> I'm very much against the API
[18:06:38 CET] <kierank> BBB: there was totally arbitrary renaming
[18:06:54 CET] <BBB> I dislike the fact they changed the API for no good reason
[18:06:59 CET] <ubitux> speaking of the devil, the last patch just got pushed
[18:07:03 CET] <BBB> but I dont really consider it a big deal or anything
[18:07:12 CET] <ubitux> batch*
[18:07:21 CET] <BBB> like, in terms of opinion * weight, my opinion is pretty negative, but the weight is pretty low
[18:07:26 CET] <nevcairiel> its not the last one, they didnt touch any  "relevant" codecs yet
[18:07:48 CET] <wm4> to be fair I think the new names are actually better understandable
[18:07:53 CET] <ubitux> ah? last irrelevant codecs batch then?
[18:08:04 CET] <wm4> but that's all I have to say about it
[18:08:06 CET] <atomnuker> too verbose, what's wrong with get_*
[18:08:10 CET] <kierank> what names did they settle with
[18:08:28 CET] <wm4> certainly seems strange that they change every single decoder now, though
[18:08:33 CET] <wm4> instead of collecting experience
[18:09:05 CET] <nevcairiel> bitstream_read
[18:09:06 CET] <kierank> atomnuker: yeah too verbose actually
[18:09:06 CET] <kierank> bitstream_read
[18:10:49 CET] <atomnuker> whoever merges should NOP the API changes
[18:11:04 CET] <nevcairiel> not going to happen
[18:11:08 CET] <atomnuker> why not?
[18:11:09 CET] <nevcairiel> that would make any future merges terrible
[18:11:19 CET] <ubitux> atomnuker: will you handle every commit coming after that?
[18:11:22 CET] <kierank> the h264 merges are all bad as well
[18:11:27 CET] <kierank> they break tons of stuff every single time
[18:11:57 CET] <ubitux> any issue we should know about recent h264 merges?
[18:12:22 CET] <atomnuker> ubitux: it wouldn't interfere with anything
[18:12:31 CET] <wm4> where are the APIs incompatible, rather than just renames?
[18:13:15 CET] <atomnuker> bitstream reading is like less than a percent of the code in a decoder
[18:13:25 CET] <jamrial> if the new reader is such a problem, we can always just noop the commit that removes the current reader, then on a case by case basis choose which codec uses which reader
[18:13:34 CET] <atomnuker> not to mention no modern codec should use rawbits, they should have an entropy encoding system
[18:14:33 CET] <nevcairiel> raw bits are still used for headers and auxiliary data
[18:14:54 CET] <ubitux> note: we have 500+ commits to merge before reaching the bitstream reader commit
[18:15:00 CET] <ubitux> so no worry, it's not for tomorrow
[18:15:09 CET] <ubitux> you have time to fix the api in libav side til we reach it
[18:15:13 CET] <ubitux> if you want to help :)
[18:15:20 CET] <kierank> maybe just enable their decoder for prores/huffhuv and the likes
[18:16:36 CET] <ubitux> kierank: btw, if you find the h264 merges to be so bad, you are welcome to help with them; we spend days on them, and it's not like we enjoy doing it
[18:17:50 CET] <atomnuker> ubitux: I bloody well tried to help but they woulnd't listen to me a year ago when I asked them to reconsider
[18:18:19 CET] <ubitux> atomnuker: i'm very much aware of the problem :)
[18:18:45 CET] <nevcairiel> the point is, we're not going to make our lives harder doing merges in the future over some cosmetic opionions =p
[18:19:14 CET] <atomnuker> its not making anything hard, have you looked at how often there's a change related to reading the bitstream?
[18:19:32 CET] <nevcairiel> as long as there is one, its making something harder
[18:20:13 CET] <wm4> atomnuker: any codecs for which this is particular bad?
[18:20:27 CET] <wm4> I mean nobody cares about fringe codec X or old crappy decoder Y
[18:21:28 CET] <atomnuker> flac, vorbis, aac and on 32 bits its much worse for huffyuv
[18:21:48 CET] <kierank> meh 32-bit
[18:21:52 CET] <wm4> we could probably merge it for most codecs (making future merges easier), while not merging it for the important cases, as jamrial suggested
[18:21:54 CET] <atomnuker> also changes significantly between compilers
[18:21:59 CET] <kierank> atomnuker: is that because of the 64-bit cache?
[18:22:07 CET] <ubitux> 32-bit should be tested on ARM, where it matters
[18:22:29 CET] <atomnuker> we'd end up with 2 bitstream readers with a different API and nobody wants that
[18:23:28 CET] <nevcairiel> 32-bit also still matters on  x86 quite a bit
[18:23:41 CET] <ubitux> does it?
[18:23:41 CET] <durandal_170> make cache size configurable
[18:24:12 CET] <nevcairiel> windows users often still use 32-bit things, which is a huge market for multimedia users
[18:26:13 CET] <wm4> there are also these dumb 32 bit only atom devices
[18:26:18 CET] <wm4> (or whatever it was)
[18:26:42 CET] <wm4> atomnuker: yeah, somewhat annoying
[18:26:53 CET] <wm4> but we also have at least 3 ways of reading byte streams
[18:27:26 CET] <bencoh> wm4: or merge it for tested codecs only
[18:27:32 CET] <jamrial> ubitux: vlc offers x86_32 builds by default. getting the x86_64 build takes a couple extra clicks
[18:27:49 CET] <jamrial> guess which one is downloaded the most :p
[18:28:00 CET] <bencoh> because there is no point in using slower code for no real reason I guess
[18:29:35 CET] <wm4> if we remove the old reader, we'd probably have to convert some ffmpeg-only codecs too?
[18:31:05 CET] <ubitux> jamrial: but is it from 32-bit platforms or clueless users?
[18:32:22 CET] <wm4> probably dumb users
[18:32:37 CET] <wm4> providing 32 bit binaries is the "safe default" on wind
[18:32:39 CET] <wm4> ows
[18:32:48 CET] <wm4> don't forget vlc is still xp compatible too
[18:33:12 CET] <wm4> and XP is less maintained than OS/2
[18:34:31 CET] <TD-Linux> I think only half of win7 installs are 64 bit
[18:35:33 CET] <nevcairiel> not so much dumb users but websites just giving out 32-bit by default
[18:35:42 CET] <nevcairiel> without even directly offering a choice
[18:35:52 CET] <nevcairiel> only indirectly a hidden choice somewhere
[18:36:22 CET] <jamrial> mpc-hc detects your user agent and offers x86_64 if you're using that
[18:36:26 CET] <iive> i thought that websites check your browser and offer executable that could run on the same system.
[18:36:58 CET] <nevcairiel> not all bother to do that
[18:37:19 CET] <jamrial> offering 32bits build by default sounds like a better safe than sorry thing. for example, an user downloading the installer and giving it to some friend on a thumb drive
[18:37:29 CET] <iive> well, i haven't downloaded windows stuff recently.
[18:37:49 CET] <iive> yeh, and 32 bit works on 32 and 64 bit windows
[18:42:06 CET] <cone-044> ffmpeg 03Michael Niedermayer 07master:481884080977: MAINTAINERS: Add myself for boadec.c
[18:51:46 CET] <cone-044> ffmpeg 03Diego Biurrun 07master:1dfc3cf89d0e: x86: hpeldsp: Split off VP3-specific bits into a separate file
[18:51:47 CET] <cone-044> ffmpeg 03James Almer 07master:ca8a3978e57c: Merge commit '1dfc3cf89d0eb026af28be46294b85d79499ffb5'
[18:55:38 CET] <cone-044> ffmpeg 03Diego Biurrun 07master:c3e83ad3b7d7: x86: hpeldsp: Use EXTERNAL_SSE2_FAST where appropriate
[18:55:39 CET] <cone-044> ffmpeg 03James Almer 07master:4d0e89ce27bc: Merge commit 'c3e83ad3b7d75f3597f47ada2616ba4479665009'
[18:58:32 CET] <cone-044> ffmpeg 03Diego Biurrun 07master:95c1df929b92: x86: hpeldsp: Drop unused function parameters
[18:58:33 CET] <cone-044> ffmpeg 03James Almer 07master:f6005907fdeb: Merge commit '95c1df929b92d81454656c222a35ec5f7db576b4'
[19:00:53 CET] <wm4> does anyone have an idea how matroskadec.c or AVPacket is supposed to deal with more than 1 BlockAdditional?
[19:01:01 CET] <wm4> the current implementation is so very short-sighted
[19:03:09 CET] <nevcairiel> BlockAdditional is a dumb concept =p
[19:03:47 CET] <BtbN> i hate HDCP, off to ebay, to buy a... splitter
[19:04:06 CET] <TD-Linux> are there any codecs that support more than one BlockAdditional?
[19:04:15 CET] <TD-Linux> it might make sense to limit the spec if not
[19:04:18 CET] <wm4> nevcairiel: yeah
[19:04:42 CET] <wm4> TD-Linux: the spec is designed to allow multiple
[19:04:49 CET] <TD-Linux> wm4, but the spec is getting rewritten
[19:05:11 CET] <wm4> duh
[19:05:38 CET] <wm4> maybe they should actually write one as a first step?
[19:05:53 CET] <nevcairiel> thats kinda what they are doing
[19:06:08 CET] <TD-Linux> https://github.com/Matroska-Org/matroska-specification
[19:07:01 CET] <wm4> oh nice
[19:07:05 CET] <wm4> not xml for a start
[19:08:01 CET] <nevcairiel> they are kinda oblivious about the biggest matroska problem though, the codec mappings
[19:08:24 CET] <TD-Linux> it's been brought up on the list, there's not a solution yet though
[19:08:40 CET] <TD-Linux> the codec IDs might get an IANA registry
[19:08:52 CET] <nevcairiel> their current spec still uses the old A_AAC/* tags that no serious muxer has written like that in for ever =p
[19:09:19 CET] <TD-Linux> yes those are getting cleaned up. already deleted a lot of the never used ones
[19:09:42 CET] <TD-Linux> I want to delete the menu specs too. in time :)
[19:09:49 CET] <nevcairiel> yeah get rid of those
[19:09:56 CET] <nevcairiel> maybe it'll stop people from asking me to build it
[19:09:59 CET] <wm4> TD-Linux: where does this happen?
[19:10:18 CET] <wm4> nevcairiel: build what?
[19:10:33 CET] <nevcairiel> support for that
[19:10:41 CET] <TD-Linux> wm4, this mailing list https://www.ietf.org/mail-archive/web/cellar/current/maillist.html
[19:10:57 CET] <wm4> ok
[19:11:02 CET] <wm4> nevcairiel: menus?
[19:11:05 CET] <wm4> do they eixst?
[19:11:12 CET] <wm4> exist even
[19:11:14 CET] <nevcairiel> not sure
[19:11:21 CET] <nevcairiel> but  sporadically people ask me about them
[19:11:26 CET] <nevcairiel> maybe they want to use them
[19:11:29 CET] <nevcairiel> but nothing supports it
[19:11:33 CET] <wm4> I think those are just idiots who hope to have dvd-in-mkv
[19:11:48 CET] <nevcairiel> this week people asked me about tracksets
[19:11:51 CET] <TD-Linux> yes libvlc even has support
[19:11:54 CET] <nevcairiel> but i dont want to do t hat either
[19:12:02 CET] <wm4> tracksets actually existed
[19:12:04 CET] <TD-Linux> and yes it's just dvd in mkv.
[19:12:14 CET] <wm4> TD-Linux: libvlc supports mkv menus?
[19:12:21 CET] <cone-044> ffmpeg 03Diego Biurrun 07master:0a39c9ac0bfd: x86: hpeldsp: Don't check for bitexact flag when initializing VP3-specific code
[19:12:22 CET] <cone-044> ffmpeg 03Diego Biurrun 07master:4efab89332ea: x86: Use *_FAST/*_SLOW CPU feature detection macros where appropriate
[19:12:23 CET] <cone-044> ffmpeg 03James Almer 07master:a956164e1eb3: Merge commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553'
[19:12:24 CET] <cone-044> ffmpeg 03James Almer 07master:ac774cfa5717: Merge commit '4efab89332ea39a77145e8b15562b981d9dbde68'
[19:12:32 CET] <TD-Linux> yup. well at least the code is still there. no guarantees it works or is even compiled
[19:13:07 CET] <wm4> lol
[19:13:50 CET] <wm4> is there a better rendering of the spec somewhere?
[19:14:21 CET] <TD-Linux> yes it renders to html like the old website http://matroska-org.github.io/matroska-specification/
[19:14:58 CET] <TD-Linux> it also gets rendered into an IETF document that's less pretty but will be the canonical verison
[19:15:14 CET] <wm4> neat
[19:15:27 CET] <wm4> oh it's the old site
[19:16:14 CET] <TD-Linux> yeah. I believe most of the text survives from the old site, so far.
[19:16:15 CET] <wm4> but quite some changes
[19:16:24 CET] <TD-Linux> but that can be fixed
[19:17:11 CET] <TD-Linux> the markdown -> RFC conversion still needs some work too, especially section 7 https://tools.ietf.org/html/draft-lhomme-cellar-matroska-01
[19:18:27 CET] <wm4> seeing some rendering errors too
[19:19:58 CET] <cone-044> ffmpeg 03Diego Biurrun 07master:7d7355aa92bb: x86: Add SSSE3_SLOW CPU flag and related convenience macros
[19:19:59 CET] <cone-044> ffmpeg 03James Almer 07master:2eab48177d74: Merge commit '7d7355aa92bb36ca0765c49a569a999bcb96f332'
[19:20:24 CET] <wm4> man why does the spec claim ms-rounded timestamps are only a problem with audio-only files?
[19:20:31 CET] <wm4> for me it's exactly the other way around
[19:20:47 CET] <TD-Linux> it probably shouldn't. there is a thread on the ML about this
[19:21:33 CET] <TD-Linux> starts here https://www.ietf.org/mail-archive/web/cellar/current/msg00744.html
[19:22:04 CET] <TD-Linux> no one has settled on a fix, but I think the current one is "ok". it depends on how much backward compat you want to break
[19:22:08 CET] <BBB> jamrial: Im not sure its a good idea to have 2 bitstream readers
[19:22:23 CET] <cone-044> ffmpeg 03Fiona Glaser 07master:8e9cd81d291b: x86: cpu: Detect Conroe CPUs and their slow shuffle unit
[19:22:24 CET] <cone-044> ffmpeg 03James Almer 07master:8d5df204d002: Merge commit '8e9cd81d291b1010c625b2766058aadf4affb537'
[19:23:11 CET] <TD-Linux> err by current one I mean this fix (though I disagree with some of the text, the fix does work) https://www.ietf.org/mail-archive/web/cellar/current/msg00745.html
[19:24:31 CET] <jamrial> BBB: it's either that, trying to fix the slowness on certain codecs, or deal with the merge conflics if we keep the current one
[19:25:36 CET] <jamrial> keeping both is the easiest path. it's just a header and there's no name collission afaik
[19:26:02 CET] <jamrial> but yes, i agree it's ugly and we already have to deal with two-of-the-same-thing thanks to prores
[19:26:46 CET] <wm4> so why do we still have those duplicate prores things
[19:31:40 CET] <jamrial> nobody bothered to check which one is better i guess
[19:32:26 CET] <wm4> 2 decoders, 3 encoders
[19:32:30 CET] <wm4> am I reading this right
[19:32:42 CET] <Compn> someone checked
[19:32:47 CET] <Compn> there were differences between them all
[19:33:03 CET] <Compn> if you want to setup double blind visual test, go for it
[19:33:16 CET] <Compn> we dont know whats best / fastest 
[19:33:30 CET] <Compn> iirc
[19:33:45 CET] <Compn> we still have duplicate asf demuxer :P
[19:33:59 CET] <jamrial> with prores it used to be a license thing. one was gpl, the other lgpl or some such
[19:34:05 CET] <Compn> that too
[19:34:11 CET] <Compn> i thought that was resolved (on the decoder side)
[19:34:15 CET] <jamrial> yes
[19:34:27 CET] <Compn> i asked youtube to test the new asf demuxer, i dont remember ever getting a response 
[19:34:40 CET] <Compn> besides 'we will test'
[19:35:45 CET] <JEEB> just like some people say that they'll work on the libvpx rate control ;)
[19:38:24 CET] <cone-044> ffmpeg 03Diego Biurrun 07master:d06dfaa5cbdd: x86: huffyuv: Use EXTERNAL_SSSE3_FAST convenience macro where appropriate
[19:38:25 CET] <cone-044> ffmpeg 03James Almer 07master:ba5d08938130: Merge commit 'd06dfaa5cbdd20acfd2364b16c0f4ae4ddb30a65'
[19:51:58 CET] <cone-044> ffmpeg 03Vittorio Giovara 07master:b4bb95938344: ratecontrol: Drop commented out cruft
[19:51:59 CET] <cone-044> ffmpeg 03James Almer 07master:1df08cae82d7: Merge commit 'b4bb9593834460bbbe0e70823f2c503cb01ad052'
[19:56:22 CET] <michaelni> jamrial, a956164e1eb3418922cae949f02ad4035f013213 changes ./ffmpeg -flags -bitexact -i ~/tickets/2414/wmv2decerror-short.asf -vframes 30  -an -f crc 
[19:56:32 CET] <michaelni> i think it should be reverted
[19:59:09 CET] <lanc> Trying to understand how the source of libavcodec works, does anyone have additional resources besides the docs?
[20:11:04 CET] <BBB> lanc: your question is overly broad, youll have to be more specific about what question you have
[20:11:19 CET] <BBB> lanc: also, if it relates to usage, please ask in #ffmpeg, this channel is for development of (not with) ffmpeg
[21:30:22 CET] <Gramner> >x86: cpu: Detect Conroe CPUs - i know it's a merge commit and I'm therefore late to the party, but it's kind of funny that we're adding explicitly targeted optimizations for a µarchitecture that's over a decade old
[21:31:53 CET] <llogan> I dealt with all of those damned mailing list bounces from Cloudmark. I guess they don't like Bulgaria. They claimed they "reset the reputation of your IP".
[21:36:21 CET] <llogan> Gramner: I thought the author was doing stuff again, but then realized it was 6 months old.
[21:37:21 CET] <Gramner> Fiona is the author because that code was ripped straight out of x264 (and yes, it was relicensed to LGPL so that's ok)
[23:12:22 CET] <BBB> Gramner: I dont think we care at all, were merging to keep code mergeable but nobody in here cares about conroe
[23:17:49 CET] <JEEB> heh, bink2 sure is popular. quite a few games that I got during the last 12 months use it.
[23:40:52 CET] <atomnuker> it has like 10 or something variations, though IIRC
[23:41:48 CET] <JEEB> yeah
[23:44:37 CET] <cone-796> ffmpeg 03Michael Niedermayer 07master:8bdba1092f50: tools/target_dec_fuzzer: Only audio uses the return value to decode packets in pieces, correct the code to match that
[00:00:00 CET] --- Wed Feb  1 2017