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

[burek]

[00:32:58 CET] <cone-478> ffmpeg 03Timothy Gu 07master:53d6bf662773: avf_showspectrum: Silence "deprecated pixel format" warning
[00:36:40 CET] <ubitux> tmm1: yeah please submit the remaining patches
[00:36:55 CET] <ubitux> ah you just did, great, th
[00:36:57 CET] <ubitux> thx
[00:58:22 CET] <tmm1> thanks for the review and merges!
[01:37:18 CET] <cehoyos> kierank; Hi, I am all for splitting patches, but this can also be done in one commit;-)
[01:37:27 CET] <cehoyos> Can you comment on my smpte patch?
[01:37:28 CET] <kierank> I was asked to have the patch split
[01:37:37 CET] <cehoyos> Do you know what it is about?
[01:38:03 CET] <kierank> I don't really know why there needs to be a smpte special mode
[01:38:06 CET] <cehoyos> (Because I only know a user sent me such a file and claims it does something useful for him.)
[01:38:17 CET] <cehoyos> Did you see the thread on -users?
[01:38:23 CET] <cehoyos> For SDI
[01:38:57 CET] <cehoyos> I suspect, the normal eac3-in-spdif mode has a too high bitrate (192kHz stereo)
[01:39:21 CET] <kierank> I can send you the spec
[01:39:30 CET] <cehoyos> Not IEC please
[01:39:32 CET] <kierank> smpte
[01:39:37 CET] <cehoyos> But if you have another one: Yes, please!
[01:39:42 CET] <cehoyos> Cool!
[01:39:57 CET] <cehoyos> I couldn't find the number the user mentioned.
[01:40:01 CET] <kierank> it's 337
[01:40:04 CET] <kierank> he made a mistake
[01:40:10 CET] <kierank> 337/338/339 are a series
[01:40:52 CET] <cehoyos> In any case: You cannot test, can you?
[01:41:42 CET] <kierank> no, I implemented it in our codebase and the scope just said "DOLBY"
[01:42:08 CET] <kierank> I don't think I have the right licence to analyse the output
[01:42:21 CET] <cehoyos> Concerning cineform: Did you test Bayer?
[01:42:51 CET] <kierank> no I don't know how to decode that
[01:42:53 CET] <kierank> bayer is not supported
[01:43:40 CET] <kierank> If I have a sample that someone is sure is RGBA I can implement that
[01:43:44 CET] <cehoyos> Bayer is supported or do I misunderstand?
[01:43:48 CET] <atomnuker> kierank: calling malloc on every frame seems wasteful, perhaps use the init function (and reject or realloc if width or height change)
[01:43:57 CET] <kierank> atomnuker: oh bugger forgot that bit
[01:44:08 CET] <kierank> was mean to write that
[01:44:12 CET] <kierank> cehoyos: no it is not supported
[01:44:29 CET] <kierank> you say "support bayer" which is like saying "support yuv" or "support rgb"
[01:44:33 CET] <kierank> there are lots of ways of storing bayer
[01:44:45 CET] <cehoyos> You mean your decoder does not support four components or do you mean the Bayer support in FFmpeg is not compatible?
[01:44:45 CET] <kierank> ffmpeg only supports a couple
[01:45:00 CET] <kierank> I have no idea
[01:45:06 CET] <kierank> because i don't know what the actual files are meant to look like
[01:45:13 CET] <cehoyos> Can you explain how I can decode four components? I wasn't successful...
[01:45:27 CET] <kierank> add an extra plane pointer I guess
[01:45:43 CET] <cehoyos> I believe the user on trac can tell us / can provide useful samples.
[01:45:52 CET] <cehoyos> As said, I failed;-(
[01:50:23 CET] <kierank> basically change all the 3's into 4's in the decoder
[01:50:51 CET] <kierank> but some files won't play afaik
[01:50:55 CET] <kierank> they have more subbands that we support
[02:00:03 CET] <cehoyos> Do you think that "aes3" would be a better name for the flag than "smpte"?
[02:00:13 CET] <kierank> no it's a smpte mapping inside AES3
[02:00:28 CET] <cehoyos> I did confirm that "16" is indeed eac3 in S338 and Atrac in IEC
[02:00:57 CET] <cehoyos> Both use identical Sync Words
[02:02:08 CET] <kierank> yes it should be the same
[02:02:15 CET] <kierank> but what pkt_offset does I dunno
[02:03:40 CET] <kierank> ah
[02:03:44 CET] <kierank> it's the repetition period
[02:04:22 CET] <cehoyos> I am not sure my patch matches the spec but it matches the sample I have...
[02:04:44 CET] <kierank> by my calculation the repetition should be 6144
[02:04:46 CET] <kierank> bytes
[02:04:58 CET] <kierank> 24576 I have no idea what that means
[02:05:00 CET] <cehoyos> The spec says "data bits in the burst_payload"
[02:06:04 CET] <cehoyos> 24576 is spdif, 6144 is what I added for aes3/smpte
[02:06:14 CET] <kierank> where does 24576 come from
[02:06:27 CET] <kierank> seems like a random number
[02:06:45 CET] <kierank> would be nice if these random numbers documented
[02:06:51 CET] <kierank> 6144 = ( 1536 / 48000 ) * 48000 * 2 * 2
[02:06:57 CET] <cehoyos> It is the number now in spdifenc which is needed to mux eac3 to spdif
[02:07:04 CET] <kierank> yes but it's plucked out of thin air
[02:07:22 CET] <kierank> my calculation calculates the duration of an ac3 frame and thus the amount of space it takes up in pcm
[02:07:28 CET] <cehoyos> No, you have to multiply 6144 by 4 because that is the IEC frame size or similar
[02:07:38 CET] <cehoyos> But this is eac3
[02:07:44 CET] <kierank> same number of samples
[02:07:49 CET] <kierank> afaik
[02:07:54 CET] <kierank> iec frame size?
[02:07:55 CET] <kierank> eh
[02:07:59 CET] <cehoyos> In any case: I can tset spdif and it works.
[02:08:03 CET] <cehoyos> I cannot test aes3
[02:08:11 CET] <kierank> yes but it's a number plucked from thin air
[02:08:15 CET] <kierank> does 6144 not work with spdif?
[02:08:46 CET] <cehoyos> But the aes3 spec requests "number of bits in burst_payload" and my patch writes "max bytes"
[02:08:53 CET] <cehoyos> No, it does not work
[02:09:12 CET] <cehoyos> Or I didn't find out how: But I have to specify 192kHz to have eac3 working
[02:09:29 CET] <cehoyos> So you have to mulitply your above calculation with 4 iiuc
[02:09:33 CET] <kierank> 48000 * 4 = 192
[02:09:37 CET] <kierank> so you have some bug somewhere
[02:09:44 CET] <kierank> confusing bytes with 2 sample pairs
[02:09:50 CET] <cehoyos> Please explain: Where is a bug?
[02:09:59 CET] <kierank> random multiplications by 4 to make things work
[02:10:00 CET] <cehoyos> Are you taliking of the existing code?
[02:10:04 CET] <kierank> possibly
[02:10:09 CET] <cehoyos> I would really like a comment about the new code from you!
[02:10:18 CET] <cehoyos> That does not contain the number "24576"
[02:10:29 CET] <kierank> " ctx->pkt_offset  = 24576;"
[02:10:37 CET] <cehoyos> That is not part of my patch!
[02:10:45 CET] <kierank> yes but it's cargo cult programming
[02:10:49 CET] <kierank> numbers that happen to work
[02:10:49 CET] <cehoyos> ctx->pkt_offset  = 6144;
[02:10:54 CET] <kierank> yes again cargo cult
[02:11:00 CET] <kierank> you have no idea where 6144 came from
[02:11:02 CET] <kierank> until I said so
[02:11:04 CET] <cehoyos> Feel free to send a patch to change it, I will test it.
[02:11:16 CET] <cehoyos> I did no, sorry to tell you.
[02:11:27 CET] <kierank> then why did you not comment it
[02:11:30 CET] <cehoyos> I would just like to discuss new code, not (working) old code!
[02:11:43 CET] <kierank> instead of in 10 years someone trying to figure out where the hell you got 6144 from
[02:11:50 CET] <cehoyos> Because I did not know the spec at the time that does not explain the value!
[02:11:56 CET] <atomnuker> kierank: 6144? that number is the exactm maximum amount of bits per frame allowed in aac
[02:12:02 CET] <kierank> atomnuker: go away
[02:12:06 CET] <kierank> totally irrelevant
[02:12:20 CET] <atomnuker> just saying I recognize the number
[02:12:25 CET] <cehoyos> I got it from the sample I have, the spec requires "ctx->length_code = ctx->hd_buf_filled*8" or similar
[02:12:27 CET] <kierank> I recognise the number 5 as well
[02:12:39 CET] <kierank> number of fingers on my hand
[02:13:05 CET] <cehoyos> And it is the number of max bytes in a ac3 apdif frame and an eac3 aes3 frame.
[02:13:32 CET] <kierank> yes but the point is you know but the code doesn't explain where random numbers from
[02:13:54 CET] <atomnuker> 6144 comes directly from the specs in aac, maybe it's the same here?
[02:14:07 CET] <kierank> no stop talking about nonsense atomnuker 
[02:14:12 CET] <kierank> it's a different codec
[02:14:17 CET] <kierank> you are like Compn
[02:14:20 CET] <cehoyos> It cames directly from the IEC spec.
[02:14:24 CET] <cehoyos> (here)
[02:14:44 CET] <kierank> what document
[02:16:31 CET] <cehoyos> IEC 61937-2
[02:16:53 CET] <cehoyos> Table 2
[02:17:01 CET] <cehoyos> Could we get back at the topic, please?
[02:17:51 CET] <cehoyos> If IEC defines "16" as ATRAC in spdif and SMPTE as eac3 in aes3, is it ok to add a flag "smpte" to activate the aes3 mode?
[02:18:03 CET] <kierank> yes
[02:18:52 CET] <cehoyos> Cool, hopefully the user is going to test it: I wonder if he was pissed because of my commet about smpte for defining identical numbers with different meaning...
[02:19:02 CET] <kierank> not sure that's the case
[02:19:57 CET] <kierank> but I don't have iec docs
[02:19:58 CET] <cehoyos> For 16 it is...
[02:20:37 CET] <cehoyos> eac3 in 21 in iec, but that is incompatible because it is 4 times bigger, they should have used another identifier.
[02:22:10 CET] <kierank> ok
[02:23:36 CET] <kierank> f
[02:41:06 CET] <Compn> lol time to pile on kierank
[02:41:13 CET] <Compn> kierank : delete system32
[02:41:27 CET] Action: Compn runs
[02:54:07 CET] <kierank> so any volunteers to write cfhd simd?
[03:04:06 CET] <atomnuker> is it not fast enough?
[03:26:02 CET] <kierank> on some files, no
[03:37:12 CET] <kierank> jamrial: how can i turn multiple statements into a switch
[03:43:42 CET] <kierank> guess I could just make it an if else...
[03:43:49 CET] <jamrial> if (abs_tag range check) { } else { switch (tab) } else if (abstag  range check) { } else { switch (tab) }
[03:43:52 CET] <jamrial> i think
[03:44:10 CET] <jamrial> assuming those abstag checks must be where they are
[03:45:33 CET] <jamrial> or maybe that wouldn't work, mmh...
[03:48:31 CET] <jamrial> can't you just put every tag check together into a single switch statement, with the two abstag range checks inside the default case?
[03:51:14 CET] <J_Darnley> kierank: i'll stick it on the bottom of my figurative todo list
[04:35:45 CET] <dinux> i want to be a contributor to ffmpeg . But I am a new comer :)
[04:36:30 CET] <J_Darnley> What do you want to do?  What can you do?
[04:36:54 CET] <Compn> dinux5 : can you do simd code optimizations ?
[04:39:23 CET] <dinux5> can you tell me what it is about?
[04:40:14 CET] <Compn> taking c code and writing asm from it
[04:40:29 CET] <dinux5> J_Darnley: I am good at C/C++ :)
[04:41:43 CET] <J_Darnley> That's a good start.
[04:42:33 CET] <J_Darnley> If you want to learn assembly then I think writing SIMD functions is a god way to learn it.
[04:42:47 CET] <jamrial> dinux5: best way to start would be familiarizing yourself with the code. look at existing codecs, formats and filters, see if you can improve/extend any or writing a new one
[04:42:51 CET] <Compn> j-b : we need someone to help organize small projects for newcomer developers....
[04:43:02 CET] <jamrial> alternatively check http://trac.ffmpeg.org/ and see if you find a bug you can fix
[04:44:10 CET] <jamrial> or yes, look at existing assembly files and try to learn how to write sse/avx SIMD code
[04:45:15 CET] <dinux5> jamrial: alright.I will do it .Thank you for the link :) 
[04:45:32 CET] Action: J_Darnley goes to bed.
[04:48:19 CET] <dinux5> Also if not confidential may i know if this summer ffmpeg will apply for opw? As I am interested in working on this :)
[04:49:18 CET] <Compn> i think we would need a sponsor for opw, i'm not sure if one has been located yet
[04:49:34 CET] <Compn>  cant remember how opw works...
[04:50:39 CET] <dinux5> yes there will be a sponsor most probably..thats right :o
[04:52:11 CET] <cone-327> ffmpeg 03Michael Niedermayer 07master:42c54d4cc3ab: avcodec/codec_desc: Add ff_aac_profiles to aac_latm
[04:53:31 CET] <Compn> dinux5 :  if you can learn ffmpeg and maybe submit a patch to fix some code, that would increase your chances of getting picked, should ffmpeg be in opw anyway. at the very least you would learn open source software collaboration to which you could use those skills on any other opw project...
[04:54:37 CET] <dinux5> Compn: that's true . 
[04:54:58 CET] <Compn> or if you've worked on open source projects before , then you dont need to do that :P
[04:58:32 CET] <dinux5> Umm..i opened the link :  http://trac.ffmpeg.org/ .. but where do i head to find a code containing a bug ? 
[04:58:58 CET] <dinux5> most of them are documentations
[04:59:55 CET] <Compn> click "view tickets"
[04:59:56 CET] <Compn> top right
[05:00:05 CET] <Compn> or click http://trac.ffmpeg.org/report
[05:00:17 CET] <Compn> er http://trac.ffmpeg.org/report/1
[05:02:46 CET] <dinux5> so here tickets implies issues ? is it so?
[05:03:37 CET] <jamrial> bugs or feature request, usually
[05:05:12 CET] <jamrial> the tickets are color coded based on priority (minor, major, etc), or if they are a feature request/enhancement
[10:06:11 CET] <durandal_1707> how to call filter that do V-A using spectrogram to synth sound?
[11:26:26 CET] <michaelni> spectrosynth ?
[13:00:07 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:e273dade7894: avcodec/mss2: Check for repeat overflow
[14:08:14 CET] <cone-578> ffmpeg 03Clément BSsch 07master:a43deea8614a: lavc/ccaption_dec: fix ASS tags
[14:24:27 CET] <cone-578> ffmpeg 03Marton Balint 07master:fdb2d4b1084c: lavf/concatdec: do not access packet if av_read_frame returned error
[14:26:53 CET] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:f587ed0cbbda: lavc/x264: Add compatibility values for coder options.
[16:13:11 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:d86d7b2486cd: avcodec/mjpegdec: Fix negative shift
[16:28:22 CET] <cone-578> ffmpeg 03Clément BSsch 07master:6d32628bf349: lavc/ccaption_dec: improve default style
[16:31:35 CET] <cone-578> ffmpeg 03Clément BSsch 07master:79061bcec121: fate: fix sub-cc font
[17:25:53 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:030c7f0309ec: avcodec/g2meet: Check for ff_els_decode_bit() failure in epic_decode_run_length()
[17:29:45 CET] <durandal_1707> I did spectrumsynth and quality is good considering 8bit input, but I have clicks
[17:57:38 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:93ac72a98dff: avcodec/dvdec: Fix "left shift of negative value -254"
[19:50:11 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:590863876d14: avcodec/aacdec_template: Check id_map
[23:11:17 CET] <ubitux> tmm1: so can't you handle the italic and underline with something like if (style & (1<<0)) av_bprintf(... "{\\i%d}", ...); if (style & (1<<1)) av_bprintf(... "{\\u%d}", ...)
[23:11:18 CET] <ubitux> ?
[23:51:04 CET] <durandal_1707> yes, I finally got it
[23:56:02 CET] <jamrial> got what?
[23:58:06 CET] <durandal_1707> jamrial: ifft in spectrumsynth
[00:00:00 CET] --- Mon Jan 11 2016