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

[burek]

[00:51:47 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:9e83ac6114de: tests/checkasm/h264qpel: Use LOCAL_ALIGNED_16()
[00:51:47 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:f467fc02b475: tests/checkasm/h264pred: Use LOCAL_ALIGNED_16()
[02:17:08 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:874b3117ed62: mpegaudiodec: copy AVFloatDSPContext from first context to all contexts
[02:17:09 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:fdf166c5d2bb: vc1dec: use get_bits_long and limit the read bits to 32
[02:17:10 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:a3d3e0a6bc39: nutdec: check maxpos in read_sm_data before returning success
[02:17:11 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:21769e3884ea: wavpack: use get_bits_long to read up to 32 bits
[02:17:12 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:dc85a7533263: huffyuvdec: validate image size
[02:17:13 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:a0f50ddcb831: pthread_frame: forward error codes when flushing
[02:17:14 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:32df1cd6ac09: ffmpeg: exit_on_error if decoding a packet failed
[02:17:15 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:7f84858dcf49: ffmpeg: only count got_output/errors in decode_error_stat
[02:17:16 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:e812220a304d: wavpack: limit extra_bits to 32 and use get_bits_long
[02:17:17 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:3c96f21d6e9d: webp: fix infinite loop in webp_decode_frame
[02:17:18 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:2d89356641f8: snow: remove an obsolete av_assert2
[02:17:19 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:44a9e2dbba3a: hevc: check slice address length
[02:17:20 CEST] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.6:088733414a65: imc: use correct position for flcoeffs2 calculation
[02:17:21 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07release/2.6:b17cec526214: update changelog
[03:49:17 CEST] <cone-469> ffmpeg 03Ivan Uskov 07master:1acb19d12bcd: libavcodec/qsvdec_h264.c: SPS parsing is now performed by MFXVideoDECODE_DecodeHeader() in libavcodec/qsvdec.c
[04:13:03 CEST] <cone-469> ffmpeg 03James Almer 07master:a176bbc873b1: avutil/softfloat: move av_sincos_sf() back to header
[06:13:08 CEST] <thrwaway> I uploaded a bunch of files to upload.ffmpeg.org per ticket #4644 (and http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/195493) but forgot to include the ticket ID in the filenames.. sorry for the confusion.
[09:33:56 CEST] <durandal_170> will someone comment my patches?
[11:43:54 CEST] <cone-479> ffmpeg 03Alexandra Hájková 07master:ee80f834cbb6: asfdec: set nb_streams to 0 in the asf_read_close
[11:43:55 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:cd4c878934a6: Merge commit 'ee80f834cbb6dbacdc1efb4c658a7d775e82ebff'
[11:51:14 CEST] <cone-479> ffmpeg 03Alexandra Hájková 07master:aed7715b8fa2: asfdec: increment nb_streams right after the stream allocation
[11:51:16 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:40e8ade9ebda: Merge commit 'aed7715b8fa295980c221f1cd095d42cd3bd74a6'
[11:54:28 CEST] <durandal_170> Daemon404: so for x32 checking in filter frame for reverse should be split in two?
[12:01:51 CEST] <ubitux> michaelni: why the check on resolution in ffv1 for the enabling of multicore?
[12:01:54 CEST] <ubitux> if (avctx->slices == 0 && avctx->level < 0 && avctx->width * avctx->height > 720*576)
[12:04:43 CEST] <rcombs> baptiste: I'd assume it's not worth it below that?
[12:04:45 CEST] <ubitux> it would be nice to have documentation on these levels
[12:04:48 CEST] <rcombs> erm, ubitux: ^
[12:04:56 CEST] <rcombs> just my guess, though
[12:05:00 CEST] <ubitux> bc -level 3 makes a real difference
[12:05:18 CEST] <ubitux> rcombs: maybe but seems a bit arbitrary
[12:05:33 CEST] <rcombs> yeah
[12:05:38 CEST] <rcombs> should at least be better-documented
[12:06:20 CEST] <ubitux> it seems there is a 270 vs 130 fps difference here whether i force -level 3 or not
[12:06:24 CEST] <ubitux> for a 512x512 input
[12:07:59 CEST] <michaelni> ubitux, higher level also means the decoder must be more recent to support it, but if people prefer we certainly could adjust the threshold 
[12:09:23 CEST] <ubitux> i think there should be no threshold on that IMO
[12:09:38 CEST] <ubitux> i mean whether the resolution change it will be decodable or not with old versions?
[12:11:30 CEST] <michaelni> if you have 16x16 pixel video you wont use slices nor benefit speedwise if you do, so why force later syntax ?
[12:12:01 CEST] <ubitux> is the threading overhead going to make a difference in speed for a 16x16?
[12:12:30 CEST] <ubitux> but anyway, if there is a threshold, why is it related to the level and not the decoding capability?
[12:12:59 CEST] <ubitux> the threading* capability sorry
[12:14:05 CEST] <michaelni> i think generally the decoder side is more important than  the encoder, encoder side is generally one, decoder many and decoders also tend to be lower end
[12:16:28 CEST] <michaelni> higher resolution videos should use slices so decoders can decode them in parallel
[12:17:19 CEST] <michaelni> its important that realtime decoding isnt prevented due to single slice high resolution video
[12:18:06 CEST] <cone-479> ffmpeg 03Anton Khirnov 07master:22ecfcd4c79c: af_channelmap: properly set the supported output channel layouts
[12:18:07 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:9c31b396413a: Merge commit '22ecfcd4c79cdf812fdf406525ddf0fd1f7114e4'
[12:19:00 CEST] <michaelni> OTOH for really low resolution slices will add significant overhead id expect and when none are used the older syntax should be fine
[12:19:37 CEST] <michaelni> but if the threshold is poorly choosen, please change it
[12:23:18 CEST] <michaelni> also with overhead i mean here bitrate overhead. For a 16x16 pixel video that should be significant to have more than 1 slice
[12:34:25 CEST] <cone-479> ffmpeg 03Tom Butterworth 07master:ebe8b5d947c4: dds: Fix the slice size computation
[12:34:26 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:157fa73992ab: Merge commit 'ebe8b5d947c41449c684f17c6826fe6bc46c0360'
[12:41:59 CEST] <cone-479> ffmpeg 03Tom Butterworth 07master:ae5a8dca675e: hap: Fix slice size computation
[12:42:00 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:b04b02100550: Merge commit 'ae5a8dca675ee544178225256893e679b750cb63'
[12:57:57 CEST] <cone-479> ffmpeg 03Alexandra Hájková 07master:7f388c0fabc5: asfdec: remove the wrong condition
[12:57:58 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:0a03271ef64d: Merge commit '7f388c0fabc51eca3106e7cc443393269435ab52'
[13:10:10 CEST] <kierank> is there a way from the api to list all installed codecs
[13:12:25 CEST] <kierank> fdk-aac is clearly installed
[13:12:27 CEST] <kierank> but it doesn't work
[13:24:44 CEST] <durandal_1707> kierank: how it doesnt work?
[13:25:03 CEST] <kierank> I have some configure scripts that end up  disabling it
[13:25:06 CEST] <kierank> when it's clearly there
[13:25:17 CEST] <kierank> but never mind
[13:25:22 CEST] <kierank> I am just going to built everything
[13:32:46 CEST] <wm4> yes, there's a way
[13:33:11 CEST] <wm4> AFAIK you can list both codecs and decoders/encoders
[13:33:20 CEST] <wm4> ffmpeg.c uses that too
[14:41:28 CEST] <wm4> so, how is closed captions support in ffmpeg?
[14:41:54 CEST] <wm4> they're not exposed like normal subtitles, are they? you still need to get the side data from the video decoder output
[14:42:09 CEST] <nevcairiel> Yes, its side data
[14:42:54 CEST] <wm4> and there's this insane lavfi filter too (what was its name?)
[14:43:13 CEST] <nevcairiel> In fact it's part of the lavfi core functions
[14:43:45 CEST] <nevcairiel> Which extracts the cc side data into a lavfi graph
[14:44:07 CEST] <wm4> but I thought lavfi has no subtitles
[14:44:24 CEST] <nevcairiel> It doesnt
[14:44:28 CEST] <nevcairiel> It's a big hack
[14:44:39 CEST] <JEEB> yeah, the decoded surfaces are "video"
[14:44:52 CEST] <JEEB> which you can then overlay on top of actual video with -filter_complex
[14:45:00 CEST] <wm4> lol
[14:45:10 CEST] <nevcairiel> No I don't think you can even do that
[14:45:15 CEST] <wm4> jesus christ on a stick etc.
[14:45:21 CEST] <nevcairiel> You can write the raw cc data to a file
[14:45:32 CEST] <JEEB> oh, CC
[14:45:34 CEST] <JEEB> that's even worse
[14:45:44 CEST] <JEEB> rip
[14:45:57 CEST] <wm4> I can't find it
[14:46:06 CEST] <wm4> maybe it was only a proposed patch? or I'm blind
[14:46:14 CEST] <nevcairiel> Blind it is
[14:46:32 CEST] <nevcairiel> It's a very obscure feature though
[15:10:53 CEST] <ubitux> wm4: nevcairiel: git grep -C2 '\[sub\]' doc
[15:12:30 CEST] <wm4> ok
[15:12:35 CEST] <wm4> this doesn't tell me much though
[15:13:23 CEST] <nevcairiel> in practice, the lavfi thing is not useful at all
[15:13:29 CEST] <nevcairiel> unless you want the cc data in a file
[15:13:31 CEST] <nevcairiel> for some reason
[15:15:47 CEST] <wm4> oh, it was libavdevice/lavfi.c
[15:16:14 CEST] <wm4> yeah, that's a terrible hack
[15:16:28 CEST] <ubitux> lavfi device is pretty useful
[15:16:49 CEST] <wm4> no, it's a terrible hack to work around ffmpeg.c being retarded
[15:17:06 CEST] <wm4> and the CC hack in it is even more terrible and hackier
[15:17:07 CEST] <ubitux> no, it's typically for users such as ffplay or ffprobe who don't want to support complex filtergraph themselves 
[15:17:15 CEST] <Daemon404> [14:16] <@ubitux> lavfi device is pretty useful <-- hitler did nothing wrong
[15:17:19 CEST] <Daemon404> thats what i read it as
[15:17:27 CEST] <wm4> (although in a way it's the right approach)
[15:17:36 CEST] <wm4> (the CC hack in the lavfi device I mean)
[15:18:11 CEST] <ubitux> i have no opinion on the cc hack
[15:18:23 CEST] <ubitux> but lavfi device itself is useful
[15:18:49 CEST] <wm4> why?
[15:19:06 CEST] <ubitux> 15:17 <@ubitux> no, it's typically for users such as ffplay or ffprobe who don't want to support complex filtergraph themselves 
[15:19:12 CEST] <ubitux> ffplay -f lavfi testsrc
[15:19:27 CEST] <ubitux> ffprobe -f lavfi "amovie=...; movie=... "
[15:19:37 CEST] <wm4> sigh
[15:19:38 CEST] <ubitux> (multiple sources when your app supports only one)
[15:19:40 CEST] <Daemon404> tl;dr the ycant be arsed to use libavfilter's terrible api
[15:19:43 CEST] <Daemon404> wm4 is right
[15:19:45 CEST] <Daemon404> it's a lazy hack
[15:19:46 CEST] <Daemon404> for a shitty api
[15:20:09 CEST] <wm4> the fabled ffmpeg high level API would make this hack unnecessary
[15:20:11 CEST] <ubitux> well, because multiple inputs are not a simple thing and most of the app are designed for only one input
[15:25:25 CEST] <durandal_1707> Daemon404: fine to push reverse fix?
[15:26:02 CEST] <Daemon404> no, it's not technically the correct fix
[15:26:13 CEST] <Daemon404> sorry, i forgot to reply
[15:26:19 CEST] <Daemon404> (i discussed it in here with nevcairiel)
[15:26:25 CEST] <Daemon404> i can reply now or send a better fix
[15:27:41 CEST] <nevcairiel> checking the other array would probably work, but the real correct fix is to separate them
[15:27:56 CEST] <nevcairiel> (or stop using the _fast version)
[15:28:11 CEST] <Daemon404> at this point _fast has no benefits
[15:28:16 CEST] <Daemon404> may as well use av_realloc 
[15:34:46 CEST] <durandal_1707> Daemon404: I want to fix this asap, so what about comitting one that check both?
[15:38:01 CEST] <Daemon404> that is ok too
[15:42:02 CEST] <noncom> hello!
[16:06:07 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:744051a57ad5: avcodec/hevc_parse: Print the name of the NAL units in addition to the numerical nal_unit_type in the debug output
[16:51:13 CEST] <cone-479> ffmpeg 03Nicolas George 07master:52c75d486ed5: lavc/hevc: rudimentary support for skip_loop_filter.
[16:55:57 CEST] <Daemon404> what an utterly asinine way to gain speed
[16:57:18 CEST] <wm4> what did you expect
[16:57:26 CEST] <wm4> h264 has all these funny speed hacks which you can enable
[16:57:32 CEST] <wm4> so of course hevc is going to get them too
[16:57:53 CEST] <Daemon404> disabling the loop filter surely wont make it look like shit
[16:57:55 CEST] <Daemon404> surely.
[16:58:08 CEST] <nevcairiel> people already asked me about skipping non-refs in hevc because their crappy machines cant play it
[16:58:17 CEST] <nevcairiel> but i'll never expose those options to the user
[16:58:23 CEST] <nevcairiel> never have for h264, never will for anything else
[17:00:29 CEST] <cone-479> ffmpeg 03Shivraj Patil 07master:fd7eadd25c77: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 lpf functions
[17:07:45 CEST] Action: BBB still waiting for ffvp9 neon
[17:13:00 CEST] <cone-479> ffmpeg 03Ivan Uskov 07master:d50ab820dacf: libavcodec/qsvdec_h264.c: refactoring: functionality of qsv_process_data() has been moved into qsvdec.c
[17:23:38 CEST] <durandal_1707> which avs filter is good denoiser?
[17:37:04 CEST] <cone-479> ffmpeg 03Shivraj Patil 07master:c03800d5921e: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 idct functions
[17:38:17 CEST] <J_Darnley> durandal_1707: the better ones I remember used scripts centered around MVTools and FFT3D
[17:38:30 CEST] <J_Darnley> was it called "qtgmc"?
[17:38:46 CEST] <Daemon404> that's for deinterlacing/bobbing
[17:38:53 CEST] <Daemon404> not denoising
[17:38:56 CEST] <J_Darnley> and to answer the question you asked a few days ago: I haven't been working on the asm.
[17:39:14 CEST] <J_Darnley> Daemon404: ah, my bad.
[17:43:17 CEST] <J_Darnley> Perhaps it was Temporal Degrain I was thinking of
[17:43:21 CEST] <J_Darnley> http://avisynth.nl/index.php/Temporal_Degrain
[17:45:26 CEST] <J_Darnley> Or maybe MC Temporal Degrain
[17:45:33 CEST] <J_Darnley> http://avisynth.nl/index.php/MCTemporalDenoise
[17:45:44 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:8eff61fd45f1: avcodec/mips/vp9_idct_msa: Replace __volatile__ by volatile
[18:00:24 CEST] <cone-479> ffmpeg 03Tom Butterworth 07master:083cbc930d07: snappy: Refactor so ff_snappy_uncompress() uses an existing buffer
[18:00:25 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:efa1e26122e3: Merge commit '083cbc930d077651ea7e3fbc32ec45352cfed7e7'
[18:40:31 CEST] <rcombs> J_Darnley: I'm MC Temporal Degrain and I'm here to say, 'spu adgw? 
[18:41:23 CEST] <JEEB> lol
[18:44:25 CEST] <cone-479> ffmpeg 03Tom Butterworth 07master:11f3d5c69b71: hap: Name enums, remove unused struct member
[18:44:26 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:cb59d29fd6b9: Merge commit '11f3d5c69b711a1f1631961921ecd20d31f8336d'
[19:21:33 CEST] <Compnn> cmon so close to 400
[19:22:22 CEST] <Compnn> nevcairiel : forcing users to re-encode all files ? :P
[19:23:51 CEST] <Compn> wm4 : closed captions are exposed as subtitles from lavf, iirc. you are talking about displaying them ? thats another question.
[19:24:39 CEST] <Compn> depending on the format.
[19:24:46 CEST] <wm4> no they aren't
[19:25:55 CEST] <AstralStorm> I see that ffmpeg does not support edit list properly if at all, right?
[19:26:06 CEST] <AstralStorm> for this reason I get invalid duration last packet
[19:26:16 CEST] <philipl> wm4: Doesn't the latest Kodi manage to show CCs correctly? Maybe can borrow some code from there
[19:26:19 CEST] <AstralStorm> I can wing the initial delay by skipping negative pts packets
[19:26:47 CEST] <AstralStorm> but the trailer is seemingly impossible to do in a general (codec independent, container independent) case
[19:27:00 CEST] <wm4> philipl: no idea
[19:27:08 CEST] <AstralStorm> I found some patches from 2014
[19:28:09 CEST] <AstralStorm> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-December/167157.html - ye olde thread
[19:28:18 CEST] <AstralStorm> any idea what should I do?
[19:29:06 CEST] <AstralStorm> I can potentially "hack it" by adding initial pts to the final packet
[19:29:13 CEST] <AstralStorm> but that seems wrong
[19:29:32 CEST] <AstralStorm> *to the duration of the final packet - trimming it
[19:30:53 CEST] <AstralStorm> that happens to be true for solo audio but might not be correct; any help?
[19:38:44 CEST] <J_Darnley> rcombs: top kek!\
[20:20:29 CEST] <durandal_1707> ubitux: look at allyuv and tell me if there is better way to sort colors
[20:21:05 CEST] <ubitux> why u no allrgb?
[20:32:01 CEST] <durandal_1707> ubitux: feel free to do it
[20:32:27 CEST] <ubitux> sure but i mean, why go for the hard way?
[20:32:50 CEST] <ubitux> btw, i see GBRP, is this on purpose?
[20:33:10 CEST] <durandal_1707> if you don't need pretty look it is easy
[20:33:33 CEST] <durandal_1707> it just for fun, I will remove it
[20:34:15 CEST] <ubitux> i would personally just increment from 0 to 255 every plane instead of trying to find a smart kind of procedural formula
[20:34:28 CEST] <durandal_1707> -f lavfi -i allyuv,format=gbrp
[20:34:43 CEST] <ubitux> btw, CONFIG_CELLAUTO_FILTER
[20:35:00 CEST] <durandal_1707> aww will fix
[20:35:54 CEST] <durandal_1707> if you need boring mode it could be added easy just add new option
[20:41:45 CEST] <ubitux> this allyuv is actually pretty
[20:42:09 CEST] <ubitux> so you sure there are all the colors?
[20:43:17 CEST] <durandal_1707> I shortly checked with sort
[20:43:59 CEST] <durandal_1707> it somehow resembles windows logo
[20:45:12 CEST] <ubitux> durandal_1707: btw, http://joco.name/2014/03/02/all-rgb-colors-in-one-image/
[20:47:06 CEST] <durandal_1707> I read all that and was not happy with output
[20:47:31 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:625bf6a55c3d: avfilter/vf_reverse: check also pts_size when reallocating
[20:47:32 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:e59315c4abce: doc/filters.texi: fix two typos in reverse filter description
[20:58:58 CEST] <cone-479> ffmpeg 03Tom Butterworth 07master:26e8247c1c0b: avcodec/hap: (trivial) clarify comment
[21:12:22 CEST] <cone-479> ffmpeg 03Tom Butterworth 07master:64539e12132c: avcodec/hap: (trivial) rename enum values and document their meaning
[21:17:27 CEST] <durandal_1707> ubitux: what you mean by #2558
[21:46:41 CEST] <cone-479> ffmpeg 03Martin Storsjö 07master:44f7df0c9879: dds: Write the palette in the native endian form
[21:46:42 CEST] <cone-479> ffmpeg 03Michael Niedermayer 07master:c6965f62a2e3: Merge commit '44f7df0c987965763c609f6dc36974b04182e58d'
[21:50:00 CEST] <kierank> durandal_1707: I'm not sure why but smptebars doesn't come out nicely on the scope
[21:50:03 CEST] <kierank> neither does hd
[21:50:13 CEST] <kierank> I'm going to investigate next week
[21:56:47 CEST] <durandal_1707> kierank: what is wrong?
[21:57:43 CEST] <kierank> I'll have to take a photo
[21:57:51 CEST] <kierank> it's weird because we use the numbers in the spec too
[22:01:40 CEST] <durandal_1707> do you read colorspace set in frame?
[22:02:41 CEST] <kierank> no, everything stays yuv
[22:09:59 CEST] <ubitux> durandal_1707: maybe i was on drug that day
[22:10:39 CEST] <durandal_1707> what is better name duck or sidechaincompress ?
[23:06:53 CEST] <jamrial> durandal_1707: the latter, probably
[23:06:54 CEST] <jamrial> why duck?
[00:00:00 CEST] --- Fri Jul 24 2015