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

[burek]

[00:02:45 CEST] <durandal_1707> mgraczyk: channel layout structs are very limited...
[00:03:16 CEST] <durandal_1707> the current ones...
[00:06:49 CEST] <wm4_> mgraczyk: what us ambisonic?
[00:06:58 CEST] <wm4_> object audio?
[00:07:55 CEST] <nevcairiel> yes
[00:08:07 CEST] <nevcairiel> but i dont believe it would fit into our channel layouts
[00:08:18 CEST] <nevcairiel> any user code would have to special case it since its not actually speakers
[00:10:21 CEST] <wm4_> yeah, something else would be needed
[00:10:42 CEST] <wm4_> AFAIK ffmpeg can use channel count without channel layout (while libav can't)
[00:11:03 CEST] <nevcairiel> we can, fate even tests it
[00:11:20 CEST] <nevcairiel> (i never understood why libav forces a layout)
[00:13:18 CEST] <wm4_> normally you know the layout, and then the channel count is redundant
[00:14:45 CEST] <nevcairiel> but when you dont, i would prefer avcodec not inventing fake information
[00:16:25 CEST] <wm4_> true
[00:16:48 CEST] <wm4_> elenril had a WIP patch to extend channel layouts to include various fucked up cases, but I guess it'll never happen
[00:17:07 CEST] <nevcairiel> you mean the complex struct?
[00:17:27 CEST] <wm4_> yes
[00:20:25 CEST] <mgraczyk> It's not quite object audio
[00:20:54 CEST] <mgraczyk> With Ambisonics, the channels have specific meaning as they do in 5.1 or stereo setups, for example.
[00:21:21 CEST] <mgraczyk> It's just that the channels do not correspond to physical speakers, but rather to a direction/shape
[00:22:21 CEST] <mgraczyk> I was not able to encode with Opus without a channel layout being imposed. Maybe I missed an option? For example, how can I encode a 16 channel WAV file with libopusenc in such a way that the result is 16 channels?
[00:22:37 CEST] <wm4_> there's currently absolutely no way in ffmpeg to represent this
[00:22:54 CEST] <wm4_> hm good question
[00:23:31 CEST] <nevcairiel> dont think you can
[00:23:45 CEST] <wm4_> should be easy with the API (except using the API is not easy), as long as the encoder doesn't require a channel layout
[00:24:07 CEST] <nevcairiel> our encode API enforces a channel layout requirement
[00:24:12 CEST] <mgraczyk> At the very least, I would like to be able to tell ffmpeg "The channel structure is unknown to you, so tell the codec that there is no channel layout"
[00:24:30 CEST] <wm4_> too bad then
[00:24:42 CEST] <mgraczyk> I think then we could add another option that means "this input is ambisonics"
[00:25:19 CEST] <wm4_> or just something to disable this check
[00:26:30 CEST] <mgraczyk> Yeah to be specific, libopusenc.c:445 specifies that Opus uses a channel_layout in ff_vorbis_channel_layouts
[00:26:39 CEST] <mgraczyk> But there is no "none" option because these are bitvectors 
[00:26:57 CEST] <mgraczyk> I think we could add the possibility for "none" which would mean that the channels have no special meaning
[00:27:18 CEST] <nevcairiel> none would be zero, which is already the terminator of these lists, so thats not possible
[00:27:32 CEST] <nevcairiel> if a encoder supports any channel layout, it could just not provide a channel layout listing
[00:28:08 CEST] <mgraczyk> but the same number of input channels can have multiple meanings, so with no channel layout listing it would not be possible to determine which way to interpret the input channels.
[00:28:33 CEST] <mgraczyk> eg, quadrophonic vs. R+L+C+LFE
[00:28:38 CEST] <nevcairiel> using a special value for channel_layout is also  likely to trip all sorts of things since many things may rely on the bitcount of the layout to equal the channel count
[00:29:33 CEST] <nevcairiel> the encoder not offering a list of supported layouts doesnt stop the user from providing one =p
[00:30:51 CEST] <nevcairiel> the only way i can think of would be adding a codec capability that it accepts a unknown channel layout
[00:31:07 CEST] <nevcairiel> hm looking at the code
[00:31:13 CEST] <wm4_> it could use the 30 or so high bits to represent "unknown" channel layouts
[00:31:16 CEST] <nevcairiel> you should be able to just pass avctx->channel_layout = 0
[00:31:29 CEST] <nevcairiel> it will warn, but not fail
[00:32:17 CEST] <nevcairiel> it only fails if you try to specify a layout and it doesnt accept it
[00:32:42 CEST] <mgraczyk> Just to play around with that, is there any way from the command line to set channel_layout to zero?
[00:33:07 CEST] <nevcairiel> -channel_layout 0?
[00:33:30 CEST] <mgraczyk> Unknown channel layout: 0
[00:34:19 CEST] <mgraczyk> We also need to change a few things on and after libopusenc.c:167 to address the FIXME and prevent accessing those arrays when channels > 8
[00:35:02 CEST] <nevcairiel> guess ffmpeg.c prevents that, but thats where i dont care anymore =p
[00:35:06 CEST] <nevcairiel> avcodec accepts 0
[00:35:53 CEST] <cone-544> ffmpeg 03Michael Niedermayer 07master:21acc4db5fa3: avcodec: Add bits_per_raw_sample to AVCodecParameters
[00:36:45 CEST] <wm4_> mgraczyk: extending the max. channel count beyond 8 would be pretty orthogonal I guess
[00:37:22 CEST] <mgraczyk> It looks like the parsing is done in libavutil/channel_layout.c, not ffmpeg.c, right?
[00:37:49 CEST] <mgraczyk> Why orthogonal?
[00:38:16 CEST] <mgraczyk> It seems that if we were to allow codecs to accept "unknown" or "don't care" channel layouts, the channel count wouldn't matter anymore, right?
[00:38:32 CEST] <mgraczyk> We shouldn't need "Unknown but 4 channels" in addition to "Unknown but 6 channels"
[00:38:52 CEST] <mgraczyk> I think if we add "unknown layout" it should be any number of channels, or a number up to a max.
[00:40:05 CEST] <wm4_> I mean, there can be classic channel layouts with more than 8 channels (although I've never seen one)
[00:40:47 CEST] <mgraczyk> Sure, and Opus doesn't have any special ones so for Opus in particular > 8 would mean "unknown" for now.
[00:43:11 CEST] <mgraczyk> What about AV_CH_LAYOUT_NATIVE? I'm not sure I understand the meaning of that one, but maybe we could just add that to ff_vorbis_channel_layouts?
[00:43:36 CEST] <mgraczyk> When passed to Opus, it would mean to do whatever the right thing is for the number of channels passed in. So for > 8, it would mean no layout (each stream coded independently).
[00:43:42 CEST] <nevcairiel> like I said, as soon as a channel layout is set, its required for the bitcount to match the number of channels
[00:44:01 CEST] <nevcairiel> adding odd special cases is not wise
[00:44:04 CEST] <nevcairiel> rather go with unset then
[00:44:44 CEST] <mgraczyk> Well it's an odd special case that is already there.
[00:45:01 CEST] <nevcairiel> its not used for channel_layout though, only for request_channel_layout, it says as much in the docs =p
[00:45:02 CEST] <mgraczyk> If that were passed to Opus, what would it mean?
[00:45:07 CEST] <mgraczyk> Ah okay
[00:49:22 CEST] <mgraczyk> Okay, let's start from basics then. The natural non-special case thing to do would be to assign a specific position in each bit vector to each ambisonic channel.
[00:49:47 CEST] <mgraczyk> Just as is done for "FRONT_LEFT", there would be an "AMBISONIC_L0_M1" channel
[00:49:50 CEST] <mgraczyk> for example
[00:50:17 CEST] <mgraczyk> The problem is that there would be at least 16 of these, using valuable bits in this bitvector in a somewhat wasteful way.
[00:50:24 CEST] <nevcairiel> except that there can be hundreds of those and we really dont want to fill our already half-full 64-bit bitmask with such bits
[00:50:29 CEST] <mgraczyk> Yeah 
[00:50:47 CEST] <mgraczyk> So maybe there is a way we could easily expand the size to a multibyte encoding, unicode style?
[00:51:20 CEST] <mgraczyk> Reserve a bit to mean "also look at this longer vector", but do so in such a way that existing codecs can completely ignore the bit and be okay.
[00:51:24 CEST] <nevcairiel> not really, i would just go with unset layout, like I said before, avcodec can deal with unset just fine
[00:52:10 CEST] <mgraczyk> Okay, so you are suggesting modifying av_get_channel_layout in libavutil/channel_layout.c so that it can parse "none" or "0" or something like that?
[00:54:13 CEST] <nevcairiel> thats just a silly ffmpeg.c limitation of not supporting numeric channel layouts
[00:54:57 CEST] <nevcairiel> and no, that change wouldnt help since ffmpeg.c specifically checks if its non-null
[00:55:06 CEST] <nevcairiel> or rather ffmpeg_opt.c
[00:55:31 CEST] <mgraczyk> Yeah but that would be easy to change, right?
[00:55:39 CEST] <nevcairiel> you would think so, but not really
[00:55:43 CEST] <mgraczyk> Just return a status flag and take an [out] arg that has the actually channel layout
[00:55:56 CEST] <nevcairiel> thats new public API
[00:55:57 CEST] <nevcairiel> which is evil
[00:56:16 CEST] <mgraczyk> Why?
[00:56:24 CEST] <mgraczyk> You can add a new function and not change the old one?
[00:56:27 CEST] <mgraczyk> right?
[00:56:49 CEST] <nevcairiel> Of course, but before we add new public functions you need to convince us that its really super useful to have it
[00:57:00 CEST] <nevcairiel> because once we do have it, we cant get rid of it anymore
[00:57:33 CEST] <mgraczyk> Okay, if you don't want to modify or augment the API, how can I get this available to the command line?
[00:58:07 CEST] <mgraczyk> Would it be better to special case certain ambisonics? For instance, I could add a "first order ambisonics" channel layout with 4 channels.
[01:00:46 CEST] <nevcairiel> Like I explained earlier, you can't do that, channel layouts need to have 4 bits set if they represent 4 channel, or 16 bits set for 16 channel
[01:02:11 CEST] <mgraczyk> Right, I forgot that. Any suggestions then?
[01:02:29 CEST] <nevcairiel> you can of course pass it using existing channel layouts to opus, and add an opus option to inform it that its ambisonic
[01:03:29 CEST] <mgraczyk> Okay, so we would change libopusenc to forgo indexing into those arrays whenever the channel count is too high or this new option is provided or something like that?
[01:04:04 CEST] <nevcairiel> it sounded like opus cant even do this right now anyway, so maybe you should finish making opus support this first :)
[01:04:33 CEST] <mgraczyk> Opus can independently code any number of channels <255
[01:04:54 CEST] <mgraczyk> It can also couple any of those 127 pairs
[01:05:01 CEST] <nevcairiel> sure, but you still need to signal somehow that the decoder has to interpret it in a certain way
[01:05:10 CEST] <nevcairiel> just giving it 16 channel doesnt inform it of anything
[01:05:47 CEST] <mgraczyk> Yes that is true.
[01:06:02 CEST] <mgraczyk> However, encoding 16 channels independently is better than not being able to encode 16 channels at once.
[01:06:03 CEST] <nevcairiel> otherwise it sounds like a rather hacky "proprietary" solution where you have to know what the file contains to interpret it, and possibly not something we should claim ffmpeg can create =p
[01:06:38 CEST] <mgraczyk> Nothing here will be proprietary, I promise!
[01:07:21 CEST] <nevcairiel> i quoted it for a reason just meaning that if the file doesnt contain all information needed to fully decode and interpet it, its not going to make many people happy
[01:07:57 CEST] <mgraczyk> Yes that is true. The Opus bitstream leaves a lot of information implicit, so you can do a lot of special case compression by only modifying the encoder.
[01:08:00 CEST] <nevcairiel> and coming up with your own "specification" is generally not a good idea
[01:08:17 CEST] <nevcairiel> did you try to talk to Xiph about ambisonic?
[01:08:24 CEST] <mgraczyk> Yes
[01:08:29 CEST] <mgraczyk> We are in communication
[01:08:56 CEST] <mgraczyk> For now we are doing as much as we can without modifying the bitstream or the decoder.
[01:09:08 CEST] <mgraczyk> So I think changes to ffmpeg will only need to be configuration changes.
[01:09:28 CEST] <mgraczyk> Or rather, adding ways to pass configuration to the codec.
[01:12:35 CEST] <wm4_> well its just a question of metadata isn't it
[01:12:58 CEST] <wm4_> so in place of whatever opus/ogg uses for channel layouts there should be some for ambisonic
[01:13:33 CEST] <nevcairiel> maybe ffmpeg -ac 16 works? I don't know what it does with the channel layout then
[01:13:35 CEST] <wm4_> it was quite horrible when flac (and maybe vorbis?) didn't have anything standard even for classic channel layouts
[01:13:41 CEST] <wm4_> don't repeat that mistake
[01:17:32 CEST] <nevcairiel> we also have various channel layouts for 4, 8, 16 channels, i dont know what channel counts ambisonic would really need, but quad, octagonal and hexadecagonal sound generic enough to use for ambisonic in combiation with a opus private option
[01:19:08 CEST] <mgraczyk> Yes that should be okay for the short term.
[01:19:25 CEST] <mgraczyk> We would also like to encode 25, 36, 49, etc channel streams
[01:19:50 CEST] <mgraczyk> Probably not for a year or so though
[01:20:26 CEST] <mgraczyk> Okay so I will work on a patch which modified libopusenc to accept 16 channels and a special ambisonic option.
[01:20:37 CEST] <nevcairiel> before thinking about actually encoding things, it would be nice to have an official xiph approved specification how to signal this in a opus stream, anything else is just super annoying in the long run, as wm4_ explained we had this with flac for a while because they didnt even specifiy ordinary 7 and 8 channel layouts
[01:21:00 CEST] <mgraczyk> I do not plan to modify the bitstream right now.
[01:21:18 CEST] <nevcairiel> so "inofficial" specifications showed up using tags, which was just stupid
[01:21:28 CEST] <mgraczyk> The header will contain a new channel_mapping value
[01:22:54 CEST] <mgraczyk> libopusenc.c:96 will change, specifically
[01:23:08 CEST] <mgraczyk> Right now it is incorrect anyway
[01:23:22 CEST] <mgraczyk> It should be 0 for coupled stereo 
[01:23:52 CEST] <nevcairiel> its only written for more than stereo
[01:23:56 CEST] <mgraczyk> In fact, for now 255 for >8 channels is totally fine with me.
[01:24:01 CEST] <mgraczyk> Ah yes you're right
[01:24:20 CEST] <nevcairiel> the question is not what is fine with you, but what lets decoders identify such files
[01:24:24 CEST] <nevcairiel> because without it, its just a hackjob
[01:24:59 CEST] <mgraczyk> Well the decoder doesn't care whether it is uncoupled or ambisonic, because the decoder doesn't know what ambisonics are
[01:25:13 CEST] <mgraczyk> So I think the best thing to do would be to use "255" rather than a new channel mapping
[01:25:20 CEST] <mgraczyk> Until the decoder is aware of ambisonics
[01:25:45 CEST] <nevcairiel> so i give you a random opus file with 4 audio channels, how do you know if its just 4 random channel or ambisonics?
[01:25:46 CEST] <nevcairiel> you dont
[01:25:49 CEST] <nevcairiel> and thats a huge problem
[01:26:08 CEST] <mgraczyk> yes, there will be a new channel mapping for that
[01:26:17 CEST] <mgraczyk> But as of right now, the problem is unsolved as well.
[01:26:26 CEST] <mgraczyk> I'm not proposing anything that would make the current state worse
[01:26:42 CEST] <nevcairiel> if ffmpeg can start creating such files, its worse! =P
[01:27:07 CEST] <mgraczyk> It's much worse if ffmpeg can't create such files though.
[01:27:21 CEST] <mgraczyk> Because we need to be able to create them.
[01:27:28 CEST] <mgraczyk> I agree, we should do this the right way.
[01:27:39 CEST] <nevcairiel> then do so
[01:27:54 CEST] <nevcairiel> and not a half-finished solution because it was easy :)
[01:28:00 CEST] <nevcairiel> such files will haunt us for years
[01:28:15 CEST] <nevcairiel> encoding and muxing files should be extremely strict to avoid creating a mess for the future
[01:28:19 CEST] <mgraczyk> It's not about easy or difficult, it's about how long it will take to get a Xiph stamp on a channel mapping number.
[01:28:41 CEST] <mgraczyk> I don't want to take shortcuts, but I'd prefer to get something working before it is perfect.
[01:28:59 CEST] <mgraczyk> So I'm going to work on a patch and I think your guidance has helped me figure out what that ought to be
[01:29:30 CEST] <mgraczyk> You don't have to accept it until everything is cohesive
[01:31:08 CEST] <nevcairiel> at least opus already implements a way to define different channel mapping strategies, so a bitstream change as such is not needed, only a new defined value once the definition of it can be worked out
[01:31:25 CEST] <nevcairiel> most other formats do not
[01:32:39 CEST] <mgraczyk> Yes that is fortunate. I am going to propose to them that we call "mapping_family == 2" (L96) mean ambisonics and that we let channel_mapping (L99) determine the meaning of each ambisonic channel
[01:32:45 CEST] <mgraczyk> Does that sound reasonable? 
[05:01:33 CEST] <cone-083> ffmpeg 03James Almer 07master:bb505cd5057c: avformat/hashenc: simplify hash_write_trailer
[12:17:05 CEST] <cone-141> ffmpeg 03Benjamin Steffes 07master:0cfe16437fce: lavfi/af_hdcd: Implement high definition audio cd filtering.
[12:19:33 CEST] <atomnuker> finally!
[12:20:05 CEST] <atomnuker> now if only there was an hdcd detection filter
[12:21:28 CEST] <rcombs> nice tables
[12:23:27 CEST] <wm4> holy shit half of the file is tables
[12:24:13 CEST] <rcombs> probably more byte-wise
[12:24:50 CEST] <wm4> will surely add a few KBs of binary size
[12:25:03 CEST] <rcombs> yum
[14:47:25 CEST] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=0cfe16437fce4c2090d39552cf63d559c139f06d
[14:47:29 CEST] <Daemon404> why the heck is this in lavfi?
[14:48:00 CEST] <wm4> because someone wrote a patch
[14:50:37 CEST] <ubitux> Daemon404: where would you have it?
[14:51:27 CEST] <RiCON> as a bsf, maybe?
[14:52:22 CEST] <Daemon404> ubitux, see my mail
[14:52:28 CEST] <Daemon404> it's literally documented as a decoder.
[14:53:05 CEST] <ubitux> so as a pcm decoder?
[14:53:11 CEST] <ubitux> sounds limited
[14:53:13 CEST] <Daemon404> we have one for e.g. bluray pcm
[14:53:36 CEST] <Daemon404> er sorry, dvd pcm
[14:53:55 CEST] <ubitux> ok, well no opinion really
[15:05:07 CEST] <wm4> ubitux: sent a patch for the subtitle thing
[15:05:18 CEST] <ubitux> i think i answered
[15:05:34 CEST] <ubitux> ml is being slow to accept my mails again
[15:05:54 CEST] <wm4> seems so
[15:06:08 CEST] <cone-889> ffmpeg 03Michael Niedermayer 07master:a7fa1e38ca76: avcodec/utils: Fix duration of ATRAC3 packets
[15:07:10 CEST] <nevcairiel> Daemon404: except you could potentially have hdcd content in any other lossless container since its basically just pcm data, having it as a filter seems most logical the way this particular format works
[15:07:24 CEST] <nevcairiel> also its been on the ML for weeks, you are late 0p
[15:11:37 CEST] <Daemon404> nevcairiel, i said i was late ;p
[15:12:09 CEST] <Daemon404> BBB, someoe mentioned you could port vp9_superframe to the new bsf api
[15:12:12 CEST] <Daemon404> still feel like it?
[15:12:20 CEST] <BBB> sure
[15:12:24 CEST] <BBB> what do I need to do?
[15:13:06 CEST] <Daemon404> WIP merge is here: https://github.com/dwbuiten/FFmpeg/commits/bsf
[15:13:33 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/commit/33d18982fa03feb061c8f744a4f0a9175c1f63ab
[15:13:37 CEST] <Daemon404> for example conversions
[15:15:15 CEST] <Daemon404> maybe look at a simple one like chomp to see how it sdone
[15:15:45 CEST] <nevcairiel> the most important thing that changes is how input and output of packets works
[15:17:02 CEST] <nevcairiel> so you can more cleanly do m:n scenarios in a bsf, which should help your filter
[15:19:49 CEST] <Daemon404> nevcairiel, i fixed the hevc bsf today... seems i can simply remove that crappy nablet hack
[15:19:52 CEST] <Daemon404> it doesnt do anything anymore
[15:20:07 CEST] <Daemon404> afaict
[15:20:36 CEST] <nevcairiel> the problem it "fixed" before was that executing it twice would try to convert the extradata twice, which resulted in failure the second time around since it wrote the new one to the avctx
[15:20:53 CEST] <ubitux> michaelni: frame_bytes / ba>0 ? frame_bytes / ba : 1
[15:20:57 CEST] <ubitux> can you please add some braces?
[15:20:59 CEST] <Daemon404> nevcairiel, and i dont think that happens anymore
[15:21:13 CEST] <Daemon404> unless i am mistaken?
[15:21:27 CEST] <nevcairiel> from what I can tell the new bsf api has an input and output codecpar
[15:21:33 CEST] <nevcairiel> how those are used is another question then
[15:21:45 CEST] <ubitux> michaelni: your spacing suggests ba>0 has the highest priority, which means you could /0
[15:22:01 CEST] <nevcairiel> if the output is then used to overwrite the input codecpar at some point, the same problem would happen
[15:22:35 CEST] <nevcairiel> no clue what the fallback code from the old API does
[15:23:33 CEST] <Daemon404> nevcairiel, im trying to figure out how the hell youve even manage to trigger this in correct code
[15:23:46 CEST] <Daemon404> you'd*
[15:24:38 CEST] <nevcairiel> use ffmpeg and specify h264/hevc_qsv as the decoder, it will then be used both during probing and during decoding, but during probing it would already have converted the extradata
[15:24:45 CEST] <nevcairiel> its the problem when a bsf is used from within a decoder =p
[15:25:31 CEST] <Daemon404> im not sure where to even look to find out
[15:25:35 CEST] <Daemon404> this is so convoluted
[15:25:38 CEST] <nevcairiel> anyway all usage of the bsfs within avcodec and avformat should be converted to the new API after its available and this can then be avoided, hopefully
[15:26:12 CEST] <Daemon404> welli cant tell if youre saying i should remove the code or not
[15:26:15 CEST] <Daemon404> ;)
[15:26:28 CEST] <nevcairiel> you should ensure it still works
[15:26:34 CEST] <nevcairiel> if the code is needed or not i dont know
[15:26:45 CEST] <Daemon404> and i dont know how the hell to test if it works
[15:26:49 CEST] <Daemon404> i dont have any qsv stuff
[15:28:52 CEST] <Daemon404> so uh?
[15:29:33 CEST] <nevcairiel> qsv has a software decoder plugin you can use =p
[15:29:45 CEST] <Daemon404> sigh
[15:30:23 CEST] <Daemon404> lemme guess
[15:30:29 CEST] <Daemon404> this is going to be a big pain in the ass to setup
[15:30:43 CEST] <nevcairiel> dunno
[15:31:08 CEST] <nevcairiel> should just be grabbing the plugin binary and the dispatcher library and headers,  the second is available on github from luca
[15:31:38 CEST] <Daemon404> its really hard to motivate myself to do this when i dont give a shit avbout qsv or nablet hacks
[15:32:45 CEST] <Daemon404> nevcairiel, also does this appyl to hevc
[15:32:46 CEST] <wm4> "nablet hacks" never caught my eye before, but maybe I was looking away
[15:32:57 CEST] <Daemon404> does qsv have a software hevc decoder
[15:33:00 CEST] <Daemon404> if not, i cant test this
[15:33:08 CEST] <nevcairiel> well h264 and hevc are exactly the same in this regard
[15:33:13 CEST] <nevcairiel> fix it in h264 and do the same for hevc
[15:33:19 CEST] <Daemon404> i dont really want to fix h264
[15:33:22 CEST] <nevcairiel> the qsv decoder code is even shared
[15:33:23 CEST] <Daemon404> outs is not easy to merge
[15:33:28 CEST] <Daemon404> i was hoping someone lse would.
[15:33:30 CEST] <Daemon404> else*
[15:33:32 CEST] <Daemon404> i'd probably scerw it up
[15:34:22 CEST] <Daemon404> im probably not even going to. someone else can help me or it wont get done.
[15:34:25 CEST] <Daemon404> simple.
[15:38:43 CEST] <Daemon404> i pushed the resolved hevc conflicts, without the sps option in it, to my bsf branch. someone feel free to test, or try and fix the h264 bsf.
[15:38:48 CEST] Action: Daemon404 is not going to
[15:46:26 CEST] <durandal_1707> SPAM, BAN HIM
[15:49:13 CEST] <cone-889> ffmpeg 03Michael Niedermayer 07master:bcf936eaeae8: avcodec/utils: Add braces to framecount computation
[15:57:11 CEST] <wm4> possibly I can take a look at the BSF shit later
[15:58:12 CEST] <ubitux> michaelni: thx
[18:24:16 CEST] <omerjerk> is there a utility function in ffmpeg to create a float value out of sign, exponent and mantissa ?
[18:25:24 CEST] <durandal_1707> no, but that is trivial in C
[18:26:15 CEST] <durandal_1707> use union
[18:27:55 CEST] <omerjerk> I'm doing it like - sign << 31 | exp << 23 | mantissa
[18:28:00 CEST] <omerjerk> I hope this is correct ?
[18:28:24 CEST] <omerjerk> I then convert the integer to float using av_int2float
[18:29:45 CEST] <nevcairiel> manually building a float sure sounds wrong
[18:32:26 CEST] <omerjerk> I have written the code up to the point where I've sign bit, exponent, and mantissa. 
[18:32:39 CEST] <omerjerk> but the final float is coming out to be wrong.
[18:36:20 CEST] <durandal_1707> omerjerk: use casting
[18:39:55 CEST] <omerjerk> like float a = (float) some_int; ?
[18:41:06 CEST] <Daemon404> just what exactly are you doing that requires manually building a float
[18:43:54 CEST] <omerjerk> I'm working on implementing the floating point format support in the ALS decoder that we have.
[18:46:03 CEST] <durandal_1707> omerjerk: just use different pointer to frame extended data 
[18:47:14 CEST] <Daemon404> omerjerk, is it float for intermediate only, or for final output?
[18:48:04 CEST] <omerjerk> both kind of.
[18:48:32 CEST] <omerjerk> I create a float variable, assign to an array, then write the array to the output. 
[18:49:53 CEST] <omerjerk> I'm creating the float like this - https://github.com/omerjerk/FFmpeg/blob/float/libavcodec/alsdec.c#L1761
[18:50:12 CEST] <durandal_1707> you dont need to create float variable
[18:51:56 CEST] <nevcairiel> if anything you should just use the mantissa and multiply it with the exponent appropriately to create the value, bitshifting to manually create the memory representation of a float seems terrible
[18:53:49 CEST] <omerjerk> okay. Thank you everyone. I can try this.
[18:57:18 CEST] <durandal_1707> this must bit bitexact
[18:57:35 CEST] <durandal_1707> so just write them as ints
[19:06:24 CEST] <cone-889> ffmpeg 03Michael Niedermayer 07master:f07923253a1b: avcodec/avcodec: Document signed/unsignedness of sample formats in relation to bits_per_raw_sample
[19:09:17 CEST] <kurosu> omerjerk, your sign is an unsigned char, shifting it left by 31 is likely not going to work
[19:10:34 CEST] <kurosu> (and e is an int but I haven't checked if that might cause issues)
[19:12:37 CEST] <omerjerk> oops
[19:12:56 CEST] <omerjerk> thanks for pointing it out.
[19:14:01 CEST] <kurosu> also, it would be prettier if you declared, when possible, variables in the codeblock where they are used
[19:14:59 CEST] <kurosu> *at the start of the codeblock
[20:56:49 CEST] <omerjerk> I'm almost done with the my patch now. :)
[20:57:01 CEST] <omerjerk> I'm properly able to decode the float values and print to the console.
[20:57:10 CEST] <omerjerk> Just had some doubt with writing to the file
[20:57:21 CEST] <omerjerk> Here's how I'm doing it currently  - https://github.com/omerjerk/FFmpeg/blob/float/libavcodec/alsdec.c#L2004
[20:57:24 CEST] <omerjerk> is this okay ?
[20:57:47 CEST] <omerjerk> because the output file is almost half the size of what it should actually be.
[21:05:12 CEST] <BBB> I think I found an actual bug
[21:05:45 CEST] <BBB> I havent bisected exactly, but a h264 raw file (annexb) used to be detected as 30fps, 30tbr, and is (as of recently) being detected as 25fps,30tbr
[21:05:50 CEST] <BBB> which causes all kind of weird issues
[21:05:56 CEST] <BBB> is this a known regression recently?
[21:07:00 CEST] <wm4> is it due to codecpar?
[21:07:50 CEST] <cone-889> ffmpeg 03Carl Eugen Hoyos 07master:139cbeb75e0f: lavc/dds: Fix GRAY8A decoding.
[21:09:38 CEST] <durandal_1707> omerjerk: how you decode file?
[21:10:06 CEST] <durandal_1707> by default codec for wav is 16bit pcm
[21:10:53 CEST] <omerjerk> but the float data us 32 bit
[21:10:57 CEST] <omerjerk> *is
[21:12:03 CEST] <omerjerk> I've the final values inside raw_float[][] array.
[21:13:13 CEST] <jamrial> BBB: probably codecpar related. maybe it used to read that info from the stream but now from the demuxer only, which seems to be hardcoded as 25 for all raw demuxers
[21:13:29 CEST] <BBB> that should probably be fixed
[21:13:42 CEST] <jamrial> yeah
[21:13:45 CEST] <jamrial> try using -framerate 30 for the input file as workaround for now
[21:17:00 CEST] <omerjerk> durandal_1707: I tried copying the bits from float to int and use the old code, even then it didn't work. (there's code written for 32 bit integer already)
[21:17:10 CEST] <BBB> jamrial: should I file a bug?
[21:17:19 CEST] <jamrial> yeah
[21:18:26 CEST] <durandal_1707> omerjerk: hard to follow you...
[21:20:11 CEST] <omerjerk> oh. sorry for that. Right now, I just want to write 32-bit integer to the output file.
[21:23:51 CEST] <cone-889> ffmpeg 03Carl Eugen Hoyos 07master:6d39132fd4af: lavf/bink: Support Monkey Island 4 (SMUSH) files.
[21:26:47 CEST] <cone-889> ffmpeg 03Carl Eugen Hoyos 07master:a676c29af5ee: lavf/bink: Cosmetics: Reindent after last commit.
[21:35:39 CEST] <BBB> jamrial: ^^
[22:20:47 CEST] <Threads> can i ask when compiling ffmpeg where does it store "Lavf56.30.100" this written application data in the source files
[22:25:26 CEST] <Shiz> why?
[22:27:49 CEST] <Daemon404> he probably wants to remove the muxer info from files he creates.
[22:32:11 CEST] <Threads> well remove or atleast change it in some way so it looks abit nicer even just putting a space between lavf 56*
[22:32:41 CEST] <Threads> if its a subject that can't be talked about i understand
[22:33:48 CEST] <Shiz> it's pretty easy to find in an obvious place anyway
[23:07:29 CEST] <rcombs> Daemon404: nevcairiel: how far out do you suppose the new BSF API is?
[23:24:19 CEST] <rcombs> also, is there a new _parser_ API on the way?
[23:27:35 CEST] <wm4> no
[23:28:16 CEST] <rcombs> alright, won't worry about those then
[00:00:00 CEST] --- Sat Apr 16 2016