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

[burek]

[01:08:20 CEST] <cone-563> ffmpeg 03Michael Niedermayer 07master:75651cd63f2d: avcodec/jpeg2000dwt: Fix order of operations in integer decomposition wavelets
[01:38:48 CEST] <cone-563> ffmpeg 03Michael Niedermayer 07master:de99ce4306b1: avcodec/jpeg2000dwt: add test for the 5/3 wavelet
[01:38:49 CEST] <cone-563> ffmpeg 03Michael Niedermayer 07master:0ce918c45b82: tests/fate: Add fate-j2k-dwt
[02:07:33 CEST] <jamrial> michaelni: "libavcodec/jpeg2000dwt.c:632:26: warning: iteration 2u invokes undefined behavior [-Waggressive-loop-optimizations]"
[02:07:43 CEST] <jamrial> the for loop should be j < 2, not j < 4
[02:33:54 CEST] <cone-563> ffmpeg 03Michael Niedermayer 07master:a75ca3ca6a0d: avcodec/jpeg2000dwt: Fix  special cases in sd_1d53()
[02:33:55 CEST] <cone-563> ffmpeg 03Michael Niedermayer 07master:116e7d5418bc: avcodec/jpeg2000dwt: Factor dwt test code out so it can be easily used with the other dwts too
[02:33:56 CEST] <cone-563> ffmpeg 03Michael Niedermayer 07master:5358953cdfb8: avcodec/jpeg2000dwt: Fill array using 2d instead of 1d accesses
[04:53:10 CEST] <kierank> nevcairiel: wow you have 7.5k posts on doom9
[04:54:45 CEST] <jamrial> his lav filters thread has almost 1k pages :p
[05:05:24 CEST] <BBB> kierank: I think vdd would be more interesting than webm summit for most ff devs
[05:05:36 CEST] <BBB> (I found it fun, but its very vp9 centric so not everyone here would care)
[07:54:38 CEST] <wisler> hi ffmpeg developers, I have a question about TrueHD and it's metadata stream for the audio objects. Is there someone trying to decoding it? Or is it impossible?
[08:42:30 CEST] <cone-561> ffmpeg 03James Almer 07master:6fb96afdd66c: avutil/fixed_dsp: remove ff_ prefix from static function
[08:54:08 CEST] <nevcairiel> kierank: gotta keep busy fighting all the misinformed trolls
[11:54:10 CEST] <wm4> what's attribute_align_arg for?
[11:56:12 CEST] <nevcairiel> It makes sure the stack is aligned
[11:56:32 CEST] <nevcairiel> Because some callers don't do that
[11:57:19 CEST] <nevcairiel> ie. msvc 32bit only has 4byte alignment not 16 byte as would be required for simd
[11:57:31 CEST] <nevcairiel> So it re-aligns
[11:58:27 CEST] <nevcairiel> I have had a few problems with some APIs not having it though, should add it on a few more
[12:04:29 CEST] <wm4> shouldn't the asm prelude do this?
[12:05:10 CEST] <nevcairiel> Not everything is asm
[12:05:35 CEST] <nevcairiel> Compilers may assume the alignment for vectorization
[12:06:24 CEST] <nevcairiel> Or even when using sse for double math
[12:07:12 CEST] <wm4> so we really have to care about an ABI mismatch in high level code?
[12:07:29 CEST] <nevcairiel> It's a simple fix
[12:07:43 CEST] <nevcairiel> And C isnt particularly high level
[12:07:58 CEST] <wm4> I wouldn't call littering every entry point a simple fix, but whatever
[12:08:01 CEST] <wm4> C is very high level
[12:08:29 CEST] <wm4> if it wasn't, we wouldn't have undefined behavior and such fun
[12:08:51 CEST] <nevcairiel> That argument is backwards as fuck
[12:10:01 CEST] <rcombs> hmm, now I wonder if there's any undefined behavior in x86
[12:10:04 CEST] <wm4> the gcc and clang devs would probably agree with that argument, though
[12:10:52 CEST] <luzie> x86 is high level :^)
[12:10:54 CEST] <rcombs> all sorts of performance oddities, but I can't immediately think up an instruction that doesn't have a well-defined result
[12:11:09 CEST] <rcombs> then again, I'm not an expert on the matter
[14:27:33 CEST] <cone-285> ffmpeg 03Michael Niedermayer 07master:5ba9ec824aa6: avcodec/jpeg2000dec: Increase tile part limit to 256
[14:27:34 CEST] <cone-285> ffmpeg 03Michael Niedermayer 07master:bb9f4f94ace5: avcodec/jpeg2000dec: Replace TPsot check by assert
[14:27:35 CEST] <cone-285> ffmpeg 03Michael Niedermayer 07master:50ee17340b9f: avfilter/formats: Add test for ff_parse_channel_layout()
[14:27:36 CEST] <cone-285> ffmpeg 03Michael Niedermayer 07master:f230b9671f9e: fate: add avfilter/formats-test
[16:49:38 CEST] <cone-285> ffmpeg 03Rodger Combs 07master:7e7256c3a496: lavc: add little-endian ADPCM_THP decoder
[16:49:39 CEST] <cone-285> ffmpeg 03Rodger Combs 07master:8e7a06aa5c10: lavc/adpcm: THP: handle packets with sample counts not divisible by 14
[17:29:25 CEST] <BBB> wm4: if I use the AVCodecContext in AVFormatContext, would that cause memory leaks?
[17:29:47 CEST] <BBB> my app is complaining that av_find_stream_info is causing leaks (the packets it reads)
[17:33:55 CEST] <nevcairiel> dont think memory leaks is one of the symptoms of this usage
[17:34:11 CEST] <cone-285> ffmpeg 03Rodger Combs 07master:d4c9eced98bb: lavf/brstm: support little-endian files (BCSTM; 3DS)
[17:43:14 CEST] <wm4> BBB: not sure what's the problem, ask elenril for details
[17:43:25 CEST] <BBB> hm, oh, its this ugly packet allocation again
[17:43:28 CEST] <BBB> so heres the problem
[17:43:41 CEST] <BBB> if I dont use av_dup_packet, I cant call av_free_packet
[17:43:49 CEST] <BBB> because it sometimes crashes on some media (I believe for y4m)
[17:44:01 CEST] <BBB> so I need to call dup_packet so I can always call free_packet
[17:44:03 CEST] <BBB> I dont understand why
[17:44:13 CEST] <wm4> no, you always call av_free_packet
[17:44:19 CEST] <BBB> the comment for the function says hack"
[17:44:22 CEST] <wm4> dup is optional
[17:44:31 CEST] <wm4> that comment is probably from 2001
[17:44:35 CEST] <BBB> ok...
[17:44:40 CEST] <wm4> and some old stuff is kept for ABI compat etc.
[17:44:44 CEST] <BBB> so if I dont dup, and its raw yuv, and I decode
[17:44:46 CEST] <BBB> is that ok?
[17:44:57 CEST] <BBB> (after that free pkt and display decoded frame)
[17:45:25 CEST] <nevcairiel> it should manage the references appropriately for you
[17:46:43 CEST] <nevcairiel> ie. in a raw case, if the input packet is ref-coutned, the frame will just ref it, and if its not ref-counted, it will copy it
[17:47:44 CEST] <ubitux> is demuxing_decoding.c not clear enough? :(
[17:48:06 CEST] <wm4> ubitux: why not have a self-explanatory API instead
[17:48:09 CEST] <nevcairiel> av_dup_packet has one obscure usecase .. it ensures the packet is ref-counted after calling it
[17:48:18 CEST] <wm4> (requires kiling all the terrible nonsense)
[17:48:37 CEST] <ubitux> wm4: nuff api changes! :(
[17:48:41 CEST] <BBB> ok so I dont need dup_packet
[17:48:52 CEST] <ubitux> we already have to deal with 3 code paths in demuxing_decoding.c :s
[17:50:10 CEST] <wm4> ubitux: what 3 code paths and why?
[17:50:19 CEST] <wm4> because you support the legacy shitcrap?
[17:50:25 CEST] <wm4> to confuse users more?
[17:50:52 CEST] <ubitux> old, new with no ref count and new with ref count
[17:51:03 CEST] <ubitux> old users might want to upgrade their code
[17:51:13 CEST] <ubitux> they need to see how it was supposed to be done, and how it's done now
[17:51:22 CEST] <nevcairiel> i hope it has a giant disclaimer which method new user should use
[17:51:23 CEST] <ubitux> it clarifies the changes that are expected to do
[17:51:46 CEST] <ubitux> ref count is an option, ppl are free
[17:52:04 CEST] <ubitux> if you wanted user not to not use it, you shouldn't have made it an option in the first place
[17:52:13 CEST] <wm4> ubitux: then you should have 3 source files
[17:52:23 CEST] <wm4> ubitux: or users are going to copy this code and think they need to support all 3 ways
[17:52:46 CEST] <ubitux> /* The different ways of decoding and managing data memory. You are not
[17:52:46 CEST] <wm4> do you really think they can know this with all the confusing mess?
[17:52:47 CEST] <ubitux>  * supposed to support all the modes in your application but pick the one most
[17:52:49 CEST] <ubitux>  * appropriate to your needs. Look for the use of api_mode in this example to
[17:52:51 CEST] <ubitux>  * see what are the differences of API usage between them */
[17:52:53 CEST] <ubitux> top of the file
[17:53:05 CEST] <wm4> and disabling refcount mode is NOT useful
[17:53:14 CEST] <ubitux> then why is it an option>?
[17:53:16 CEST] <wm4> it's more like a "what the fuck are you doing" kind of thing
[17:53:19 CEST] <wm4> because compatibility
[17:53:23 CEST] <wm4> for no reason
[17:53:24 CEST] <BBB> does ffmpeg.c use av_dup_packet()?
[17:53:31 CEST] <nevcairiel> the API didnt necessarily change when ref-counting was added
[17:53:40 CEST] <nevcairiel> the "old" API is way older than ref-counting
[17:54:13 CEST] <nevcairiel> so making it optional prevented a lot of silent failures
[17:54:40 CEST] <nevcairiel> because same api with different behavior is always going to get a lot of people
[17:56:59 CEST] <wm4> I maintain that it would have been possible to make it perfectly compatible with refcounting enabled
[17:57:12 CEST] <wm4> but maybe I missed some detail or something
[17:58:13 CEST] <nevcairiel> it would've been ugly ass code for one
[17:58:52 CEST] <wm4> emulating the non-refcounted API is uglier
[17:59:15 CEST] <nevcairiel> it would really be somewhat siimilar, just with more tracking and checks
[18:00:13 CEST] <BBB> so what is the correct way to deal with refcounted decoded frames?
[18:00:22 CEST] <nevcairiel> just free them when you are done
[18:00:24 CEST] <BBB> I set avctx->refcounted_frames = 1;
[18:00:25 CEST] <BBB> and now?
[18:00:34 CEST] <BBB> thats all?
[18:00:35 CEST] <nevcairiel> call av_frame_free once you dont need it anymore
[18:00:36 CEST] <BBB> ok
[18:00:57 CEST] <nevcairiel> (or _unref if you have a persistent AVFrame instance which you keep re-using)
[18:01:20 CEST] <wm4> do you still need to call unref before decode?
[18:01:44 CEST] <nevcairiel> I hope so, I hate implicit memory freeing magic
[18:02:02 CEST] <wm4> how is it implicit
[18:02:10 CEST] <nevcairiel> i dont do it explicitly
[18:02:14 CEST] <nevcairiel> hence, implicit
[18:02:17 CEST] <BBB> Im confused
[18:02:17 CEST] <ubitux> BBB: look at occurences of API_MODE_NEW_API_REF_COUNT in doc/examples/demuxing_decoding.c maybe
[18:02:22 CEST] <BBB> lets say I do this:
[18:02:25 CEST] <nevcairiel> just dont listen to wm4's trolling
[18:02:33 CEST] <BBB> AVFrame *pic = av_frame_Alloc();
[18:02:39 CEST] <BBB> avcodec_decode_video2(.., pic);
[18:03:14 CEST] <BBB> if (got_frame && res == 0) { AVFrame *dst = av_frame_alloc(); av_frame_ref(dst, pic); add_to_queue(dst); }
[18:03:25 CEST] <BBB> and then I unref when I remove it from the queue and am finished using it
[18:03:27 CEST] <BBB> is that bad?
[18:03:34 CEST] <nevcairiel> you can just add pic to the queue
[18:04:06 CEST] <BBB> probably...
[18:04:07 CEST] <Mavrik> av_frame_alloc implicitly adds 1 refcount
[18:04:15 CEST] <Mavrik> so you'll have to unref it twice to make it go away
[18:04:23 CEST] <Mavrik> in your case (alloc + ref -- count 2)
[18:04:31 CEST] <wm4> there are no visible refcounts at all
[18:04:35 CEST] <wm4> it's transparent
[18:04:47 CEST] <wm4> so it's more like each AVFrame is one refcount
[18:04:48 CEST] <nevcairiel> thats not true, alloc creates an empty AVFrame without any ref-counted data buffers
[18:05:06 CEST] <Mavrik> doh, yeah
[18:05:15 CEST] <nevcairiel> the full AVFrame isnt refcounted, only the data inside is
[18:05:21 CEST] <Mavrik> I mistook a call, should really check the doc before saying something. -_-
[18:05:22 CEST] <wm4> so don't think about refcounts, just AVFrame
[18:08:11 CEST] <atomnuker> anyone knows how to get the channel map from avctx->channel_layout?
[18:08:32 CEST] <nevcairiel> whats a "channel map"
[18:08:48 CEST] <nevcairiel> because in my mind thats the thing channel_layout actually is
[18:09:35 CEST] <wm4> it is
[18:09:49 CEST] <rcombs> maybe the order the channels are encoded in? (which I think is LSB->MSB in AVCodec?)
[18:10:10 CEST] <atomnuker> I just need some way to get the position/label (e.g. FL, FR, BR, etc.)
[18:10:27 CEST] <nevcairiel> there is probably some sort of API for that
[18:11:00 CEST] <rcombs> sounds like you want av_get_channel_layout_string
[18:11:25 CEST] <rcombs> that or av_get_channel_name
[18:11:56 CEST] <atomnuker> yep, that'll work, thanks
[18:12:15 CEST] <wm4> you just need to understand wtf channel_layout means
[18:12:25 CEST] <wm4> libavutil/channel_layouts.h
[18:12:32 CEST] <wm4> minus s
[18:12:40 CEST] <Mavrik> or av_get_channel_layout_channel_index
[18:13:53 CEST] <nevcairiel> its the same as the wav channel mask, I would think thats a concept people know
[19:21:05 CEST] <rcombs> durandal_1707: earlier today I was sent some BCSTM samples that give garbage on the last frame with my current patches; it's because of an inconsistency between the sample count and the used-byte count in the header
[19:21:42 CEST] <rcombs> durandal_1707: there are 2 options to fix it; 1 is to adjust the used-bytes count to fit the number of samples specified, as this patch does: https://gist.github.com/36af640e5f1d2603b0c6
[19:22:06 CEST] <rcombs> the other is to adjust the sample count to match the used-bytes count
[19:23:56 CEST] <durandal_1707> I encountered something similar with brstm files
[19:26:32 CEST] <durandal_1707> does normal files decodes same with patch?
[19:50:07 CEST] <cone-285> ffmpeg 03Rodger Combs 07master:db426031dd27: lavf/brstm: allow larger block sizes
[19:50:08 CEST] <cone-285> ffmpeg 03Rodger Combs 07master:6b547180b949: lavc/adpcm: THP: allow channel counts up to 10
[20:12:05 CEST] <cone-285> ffmpeg 03Simon Thelen 07master:7cbb52ecab90: libavfilter/formats: Fix parsing of channel specifications with a trailing 'c'.
[20:16:19 CEST] <rcombs> durandal_1707: fate says yes
[20:19:21 CEST] <durandal_1707> but what about other brstm files?
[20:20:11 CEST] Action: rcombs tests his batch of Fire Emblem BRSTMs
[20:24:03 CEST] <rcombs> durandal_1707: but thanks for reminding me that I need to adjust the BFSTM tests
[20:24:52 CEST] <rcombs> because I fixed that endianness problem and haven't done that yet
[20:27:24 CEST] <rcombs> &oh, and apparently one of my changes (most likely the ADPC/SEEK table one) did break the ADPCM decode test
[20:27:57 CEST] <rcombs> but the file sounds fine, and I believe the new behavior is closer to what Nintendo's decoder actually does
[20:36:23 CEST] <durandal_1707> update the fate tests then, please
[20:46:24 CEST] <rcombs> yup, arranging things so they never break
[21:09:26 CEST] <rcombs> ubitux: around to talk ass_split?
[21:09:36 CEST] <Daemon404> oh my.
[21:10:17 CEST] <rcombs> :|
[21:10:21 CEST] <rcombs> I didn't name the file
[21:10:50 CEST] <Daemon404> i want to name a file jesus.c or ourlordandsavior.c
[21:10:58 CEST] <Daemon404> do you have a moment to talk about jesus.c?
[21:11:09 CEST] <halfie> hi, I am trying to write an input bitsream filter. I can get "chomp" filter to apply just before the data is written to the output file. however, no luck in getting it to work on input data.
[21:11:28 CEST] <rcombs> a while ago someone asked if I "ha[d] a moment to talk about backups"
[21:11:48 CEST] <rcombs> (because they wanted to ask some questions about how I handle backups)
[21:12:04 CEST] <rcombs> but I parsed it as "do you have a moment to talk about our lord and savior, backups?"
[21:12:13 CEST] <rcombs> (which is also 100% accurate)
[21:12:14 CEST] <halfie> "ffmpeg -bsf:a chomp -i  test.mp3 -vn -acodec vorbis -ac 2 -ab 96k -f ogg -strict -2 -v debug OUTPUT" results in "Option bsf:a (A comma-separated list of bitstream filters) cannot be applied to input file test.mp3 -- you are trying to apply an input option to an output file or vice versa. Move this option before the file it belongs to".
[21:13:08 CEST] <halfie> I would like to get chomp to process encoded data in "test.mp3" before further stuff happens.
[21:14:43 CEST] <rcombs> [14:13:54]  <@barometz>	rcombs: our lord and saviour, backblaze
[22:02:34 CEST] <RiCON> <@Daemon404> i want to name a file jesus.c or ourlordandsavior.c <- there's a fb2k called foo_jesus
[22:02:40 CEST] <RiCON> +plugin
[22:03:23 CEST] <Daemon404> what does it do
[22:03:35 CEST] <RiCON> it autosaves user configurations
[22:03:38 CEST] <RiCON> :)
[22:52:14 CEST] <cone-285> ffmpeg 03Michael Niedermayer 07master:e70fd57de5ea: avcodec/mqcenc: Remove unused variable
[23:23:52 CEST] <Polochon_street> Hey! I had a problem with duplicate FLAC tags, and I found that it comes from the libavformat/oggparsevorbis.c:178 (http://pastebin.archlinux.fr/1159258), but I don't know what I should do
[23:24:19 CEST] <Polochon_street> I suppose the AV_DICT_APPEND is here for a reason, but when I remove it, the issue goes away
[23:24:27 CEST] <Polochon_street> (from     ALBUM           : Mezzanine;Mezzanine
[23:24:35 CEST] <Polochon_street> to ALBUM           : Mezzanine
[23:25:08 CEST] <Polochon_street> maybe I could add an if clause to see if the two concatenated strings are identical?
[23:25:33 CEST] <nevcairiel> you should probably find out why it even does parse it twice
[23:26:26 CEST] <Polochon_street> it's weird, because when I try to printf ct, I only have each tag once
[23:27:28 CEST] <c_14> Polochon_street: it might be https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2015-February/168509.html
[23:28:36 CEST] <ubitux> rcombs: our savior ass_split? go for it
[23:31:37 CEST] <Polochon_street> c_14: yes, you're right! So, I just need to wait for the patch to be applied to ffmpeg in later versions?
[23:33:38 CEST] <c_14> Well, it's been lying there since February. Someone probably needs to revive it.
[23:36:25 CEST] <Polochon_street> well, it's the first time ever I contribute to a free project, and it seems they are arguing about something I completely don't know. Should I reply to the last mail?
[23:41:09 CEST] <c_14> Polochon_street: you can try replying to the patch itself
[00:00:00 CEST] --- Sun Jun 21 2015