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

[burek]

[01:01] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:530bf8ece6f8: avfilter/vf_eq: Fix clipping code
[01:34] <cone-701> ffmpeg.git 03Andreas Cadhalpun 07master:f8716d1e56d5: configure: use ar and ranlib in deterministic mode if available
[01:55] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:f5b3257c506e: avfilter/vf_eq: mark src as const
[02:57] <compn> <michaelni at gmx.at> (expanded from <webmaster at mplayerhq.hu>): host
[02:57] <compn>      mx01.emig.gmx.net[213.165.67.115] said: 550-Requested action not taken:
[02:57] <compn>      mailbox unavailable 550 invalid DNS A/AAAA resource record (in reply to
[02:57] <compn>      MAIL FROM command)
[02:57] <compn> lol gmx.at 
[04:09] <cone-701> ffmpeg.git 03Michael Niedermayer 07master:aa508a9c5f63: fate: Fix bitexactness for vsynth3-dnxhd-1080i-colr
[05:12] <aetasx> awesome.  new black sails
[05:19] <wm4> so there's colr writing now, but not reading?
[05:19] <wm4> including colorspace guessing directly in the format specific muxer, awesome
[05:22] <aetasx> just realized I was in the completely wrong channel
[11:23] <cone-693> ffmpeg.git 03Stefano Sabatini 07master:afa3c996fed4: lavfi/lut: apply minor compute_gammaval709() doxy fix
[12:46] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:2af82a1ad9f7: hevc: store the escaped/raw bitstream in HEVCNAL
[12:46] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:06894f1a04dd: hevc: store the short term rps flag and size in the context
[12:46] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:b2e9b0f5d4dc: hevc: add hwaccel hooks
[12:47] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:f8ecffa9b7e4: hevc: reindent after previous commit
[12:47] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:36962ad2339d: Add DXVA2 HEVC HWAccel
[12:47] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:5f2cdf9c3cc5: ffmpeg_dxva2: add hevc support
[12:57] <ubitux> libavfilter/vf_fspp.c:    {  0,  48,  12,  60,   3,  51,  15,  63, },
[12:57] <ubitux> libavfilter/vf_owdenoise.c:    {  0,  48,  12,  60,   3,  51,  15,  63 },
[12:57] <ubitux> libavfilter/vf_pp7.c:    {  0,  48,  12,  60,   3,  51,  15,  63, },
[12:57] <ubitux> libavfilter/vf_spp.c:    {  0,  48,  12,  60,   3,  51,  15,  63 },
[12:57] <ubitux> we should probably factorized this ordered dithering table
[13:02] <cone-693> ffmpeg.git 03Anton Khirnov 07master:f9f883af4fe6: h264: simplify code in flush_dpb()
[13:02] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:ed8de1570db8: Merge commit 'f9f883af4fe615a832407a657752e248a96c6280'
[13:09] <cone-693> ffmpeg.git 03Anton Khirnov 07master:1dd021929f81: hevc: clear unused refs on failure
[13:09] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:74e5a5a849bc: Merge commit '1dd021929f8157b88529ce1e6ab6351dd2899e89'
[13:11] <durandal_1707> ubitux: what about changing pallete in palletegen when scene changes?
[13:21] <cone-693> ffmpeg.git 03Anton Khirnov 07master:443b71928b2f: hevc: unref the current frame if frame_start() fails
[13:21] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:a7fa1b9aa104: Merge commit '443b71928b2f36362e805c037751e6c3c79ea4e8'
[13:30] <cone-693> ffmpeg.git 03Andreas Unterweger 07master:749a89d1b8bb: examples/transcode_aac: properly select the output sample format
[13:30] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:010311d67337: Merge commit '749a89d1b8bb73b4d4f14c48f33259a1300c1761'
[13:36] <cone-693> ffmpeg.git 03Andreas Unterweger 07master:c9b19ac8928c: examples/transcode_aac: fix a typo
[13:36] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:d078d57fb769: Merge commit 'c9b19ac8928c6c9b7f25c3988177204f110d5e0e'
[13:54] <cone-693> ffmpeg.git 03Andreas Unterweger 07master:3a70c0c95fea: examples/transcode_aac: generate proper PTS and set the muxer timebase
[13:55] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:e5c28d4f9a72: Merge commit '3a70c0c95feacb3844d05eebd579fc8189a77eee'
[14:02] <ubitux> durandal_1707: just replied to you on the ml
[14:03] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:b0593a4bca13: hevc: pass the full HEVCNAL struct to decode_nal_unit
[14:03] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:36779a84051e: hevc: store the escaped/raw bitstream in HEVCNAL
[14:03] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:183bffb3a3c4: Merge commit 'b0593a4bca138f1f026d8c21e8c3daa96800afe2'
[14:03] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:f35c4f4a17a4: Merge commit '36779a84051eae6744cc936d91b1d428143665ba'
[14:21] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:4b95e95dbae5: hevc: store the short term rps flag and size in the context
[14:21] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:e72e8c5a1df6: hevc: add hwaccel hooks
[14:21] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:2b5fa0e0be11: Merge commit '4b95e95dbae58c9b60891284bf8b5bbd83e5293a'
[14:21] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:4e40e6128769: Merge commit 'e72e8c5a1df61447ac7af750531e96e8b62d02ba'
[14:33] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:b82722df9b29: hevc: reindent after previous commit
[14:34] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:7e850fa67e32: Add DXVA2 HEVC HWAccel
[14:34] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:2d4b8af4f688: Merge commit 'b82722df9b2911bd41e0928db4804067b39e6528'
[14:34] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:b6938c94d641: Merge commit '7e850fa67e32ebe98581c2e4ca4a4655dee7f116'
[14:36] <saste> durandal_1707, what happened to the lut16 code in eq2? why did you remove it?
[14:37] <saste> my assumption is that it was not used in mp=eq2, right?
[14:37] <durandal_1707> it was only one line
[14:37] <durandal_1707> it is used by mp=eq2
[14:38] <durandal_1707> but -benchmark showed mp=eq2 is slower so i did not cared to add lut16 
[14:38] <saste> durandal_1707, so how is that mp=eq2 is bit-exact with eq?
[14:38] <durandal_1707> so i just removed that single line in filter context because arwa didn't added more lut16 code
[14:39] <durandal_1707> saste: i changed order of options to match mp=eq2
[14:39] <durandal_1707> end tested contrast, brightness and saturation at least
[14:40] <arwa> But the options are still not matching the order in mp=eq2 code.
[14:40] <saste> so the difference is related to gamma?
[14:40] <durandal_1707> i did not tested gamma at all, but it should be bit-exact
[14:40] <saste> arwa, that's OK, since we plan to remove gamma correction from eq
[14:40] <arwa> Okay.
[14:41] <saste> mp=eq2=GAMMA:CONTRAST:BRIGHTNESS:SATURATION
[14:41] <arwa> I tested for gamma, it was working fine.
[14:41] <saste> eq=CONTRAST:BRIGHTNESS:SATURATION
[14:41] <durandal_1707> no lavfi is in alphabetical order
[14:42] <durandal_1707> actually not, ignore me
[14:42] <saste> so, again, mp=eq2 is using lut16 code, eq is not, and yet they are bit-exact
[14:42] <saste> how can it be? sorry if I'm dumb and missing something
[14:42] <durandal_1707> lut16 is just bigger lookup table
[14:43] <arwa> Maybe it does the same thing, but its little faster.
[14:44] <arwa> Because datatype for lut is uint8_t and for lut16 is uint16_t
[14:44] <saste> arwa, yeah, I think so
[14:44] <durandal_1707> lut16 comes from michaelni 
[14:53] <cone-693> ffmpeg.git 03Hendrik Leppkes 07master:a7e038049730: avconv_dxva2: add hevc support
[14:53] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:a1cdd1f08e06: Merge commit 'a7e0380497306d9723dec8440a4c52e8bf0263cf'
[15:06] <cone-693> ffmpeg.git 03Anton Khirnov 07master:cf1e0786ed64: error_resilience: move the MECmpContext initialization into ER code
[15:06] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:3d0411707839: Merge commit 'cf1e0786ed64e69614760bfb4ecd7adbde8e6094'
[15:16] <cone-693> ffmpeg.git 03Anton Khirnov 07master:9404a47a2d1d: h264: move parser-only variables to their own context
[15:16] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:6e57d2da9058: Merge commit '9404a47a2d1df418946a338938eb6cdb3afed474'
[15:22] <cone-693> ffmpeg.git 03Anton Khirnov 07master:ecab21ac47d0: h264: do not reset the ref lists in flush_change()
[15:22] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:ad3412d0283b: Merge commit 'ecab21ac47d0d4ca604bebf494017ae5090853a8'
[15:35] <kierank> ubitux: is there a way of getting a triangular wave with eval?
[15:36] <ubitux> use if() to get a 1 -1 which you multiply by t%period (use mod() for %)
[15:36] <ubitux> i guess?
[15:37] <ubitux> you can probably avoid the if() being smart
[15:49] <ubitux> kierank: ffplay -f lavfi -i "aevalsrc='abs(mod(t*100,4)-2)-1',showwaves"
[15:49] <kierank> Thanks will try later
[15:50] Action: kierank was going to Fourier decompose the wave
[15:51] Action: av500 waves
[15:52] Action: ubitux shows
[15:52] Action: Daemon404 transforms
[15:52] Action: saste decomposes
[16:02] <cone-693> ffmpeg.git 03Anton Khirnov 07master:58ae8d595724: h264_parser: restore a comment lost in 0268a54
[16:02] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:f25f15b6e1c4: Merge commit '58ae8d595724150c407ca2c2df3aa4bd5580397c'
[16:06] <reynaldo> ubitux: you around?
[16:06] <ubitux> reynaldo: yep
[16:07] <reynaldo> cool, willc continue privately ->
[16:07] <ubitux> yep
[16:14] <cone-693> ffmpeg.git 03Anton Khirnov 07master:167e004e1aca: h264: drop any pretense of support for data partitioning
[16:14] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:392080cbe528: Merge commit '167e004e1aca7765686ed95d7cd8ea5064d4f6f6'
[16:39] <durandal_1707> michaelni: will you comment on libmpcodecs removal?
[16:43] <ubitux> durandal_1707: softpulldown doesn't work in mplayer?
[16:43] <durandal_1707> it works differently in mpv
[16:44] <durandal_1707> i have not compiled mplayer here
[16:45] <ubitux> does it work with mpv?
[16:46] <durandal_1707> in mpv it is most likely broken
[16:47] <michaelni> durandal_1707, ill reply later, ping me in case i forget
[16:49] <durandal_1707> also mp=softpulldown drops all frames by default
[17:00] <durandal_1707> and for normal progressive videos it acts like interlacer
[17:05] <cone-693> ffmpeg.git 03Anton Khirnov 07master:f771b3ab5d3c: avidec: do not export stream_codec_tag
[17:05] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:be023405a7cd: Merge commit 'f771b3ab5d3c0b763ee356152be550f4121babd0'
[17:05] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:a76440239428: avcodec/h263dec: Try to use codec_tag instead of the stream_codec_tag
[17:28] <cone-693> ffmpeg.git 03Anton Khirnov 07master:e44b58924fe7: lavc: deprecate unused AVCodecContext.stream_codec_tag
[17:28] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:3c831fba0869: Merge commit 'e44b58924fe7b180bf8b0c277c15d1a58210a0e9'
[17:31] <arwa_> How do I generate an image with blocky artifacts for testing the output?
[17:31] <nevcairiel> encode something wth a very low bitrate? :d
[17:32] <Daemon404> http://needsmorejpeg.com/
[17:32] <nevcairiel> heh
[17:35] <arwa_> But, I need to use some encoder from FFmpeg.
[17:39] <kierank> encode with mpeg2
[17:39] <kierank> or something like that
[17:39] <nevcairiel> default mpeg2 or mpeg4 settings are probably blocky as hell
[17:43] <durandal_1707> michaelni: could you please take look at softpulldown port by me to find out why it differs with mp version?
[17:58] <cone-693> ffmpeg.git 03Anton Khirnov 07master:80a11de7dca3: nutenc: do not use has_b_frames
[17:58] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:b44456c90896: Merge commit '80a11de7dca315505bf203ce9c8c016e71724fd2'
[18:16] <cone-693> ffmpeg.git 03Anton Khirnov 07master:728685f37ab3: Add a side data type for audio service type.
[18:16] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:62a82c66cd3f: Merge commit '728685f37ab333ca35980bd01766c78d197f784a'
[18:21] <kierank> durandal_1707: +1 about mpcodecs
[18:24] <nevcairiel> Sometimes I wonder if some people are just too dense or if I'm just that smart, but i've never had big troubles understanding the ffmpeg API or the source code behind it, yet some people make it a holy mission to call it "cryptic" at best, or using strong swear words at worst
[18:24] <nevcairiel> Certainly its not perfect and makes some things more complex than they need to be, but its not "hard" to use it, its just a bit time consuming to write boilerplate that may not be necessary
[18:25] <JEEB> pretty much
[18:25] <nevcairiel> also, i should unsub from libav-user
[18:28] <wm4> too much trolling?
[18:28] <nevcairiel> well its the thread you and that other guy are trolling each other about that cocoa api
[18:28] <Daemon404> too much dumb
[18:30] <kierank> the problem is I think people don't understand containers, timestamps etc
[18:30] <nevcairiel> even a high-level API would need to touch that at some point, unless the toplevel API is "Play(file)" and a new window pops up :d
[18:33] <cone-693> ffmpeg.git 03Anton Khirnov 07master:4227e4fe7443: lavf: add a convenience function for adding side data to a stream
[18:33] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:0bdcc27d9598: Merge commit '4227e4fe7443733fb906f6fb6c265105e8269c74'
[18:33] <wm4> nevcairiel: well, in most cases you'd get pretty good results by naively drawing a RGBA frame using some GUI widget API and assuming fixed frame rate
[18:34] <wm4> the low level API requires understand packets and stuff
[18:34] <wm4> +to
[18:34] <wm4> so there are some orders of magnitudes of understanding between those
[18:35] <nevcairiel> I dunno, a naive decoding loop that just gives you RGB in the end isnt that complex, you dont really need to understand more of the "packet" than to know that you get it from one API and shove it into another
[18:36] <Daemon404> wm4, packets AND parsers
[18:36] <Daemon404> and perhaps bsfs
[18:36] <nevcairiel> it might help the whole issue if sws had a AVFrame API that was easy to use, instead of having to figure out how to pass stuff to sws
[18:36] <Daemon404> sws API is easy as pie to use
[18:36] <Daemon404> a few calls, done
[18:36] <Daemon404> lavf and avc are super tedious
[18:36] <Daemon404> and nonobvious
[18:37] <Daemon404> esp. with the multiple-frames-per-packet, multiple-packets-per-frame, parsers, bsfs
[18:37] <nevcairiel> assuming you just want decoding, you dont need to know this
[18:37] <Daemon404> plus the need to flush
[18:37] <Daemon404> you do
[18:37] <Daemon404> because you need to make teh loop handle both
[18:37] <nevcairiel> bsfs are irrelevant for decoding, as are parsers, those are handled in avformat internally
[18:37] <Daemon404> well ok
[18:37] <wm4> lavf would need a way to configure a buffer sink/src with an AVFrame, and it'd be relatively simple to use
[18:38] <Daemon404> anyway i just use FFMS_GetFrame for that stuff
[18:38] <Daemon404> and ignore all this
[18:38] <nevcairiel> the only thing you need to handle is the initial setup, and then a loop with av_read_frame(), and avcodec_decode_video2(), and then sws
[18:39] <nevcairiel> well plus branching of between different streams, i guess
[18:39] <Daemon404> you need to decrement packet size if it is not consumed
[18:39] <Daemon404> and pass it again
[18:39] <nevcairiel> not for video
[18:39] <nevcairiel> but for audio, yes
[18:39] <nevcairiel> (technically the API allows that for video too, but noone does t hat there, and no decoder expects you to)
[18:40] <Daemon404> what about packed bframe AVIs?
[18:41] <nevcairiel> i think the parser splits those in avformat
[18:41] <Daemon404> right
[18:41] <Daemon404> i dont get that
[18:42] <Daemon404> why have a parser do that, but also have the API allow multiple frames per packet
[18:42] <nevcairiel> frame threading
[18:42] <Daemon404> right...
[18:42] <nevcairiel> i guess the API still allowing that is just old
[18:42] <nevcairiel> but not even the ff* tools  do this for video
[18:43] <Daemon404> lol fun
[18:43] <nevcairiel> and even on the audio side its very few codecs that require it
[18:43] <Daemon404> but teh ff tools dont even follow the documented api
[18:43] <Daemon404> so.
[18:43] <Daemon404> yeah.
[18:43] <wm4> <nevcairiel> and even on the audio side its very few codecs that require it <- I argued for removing this API artifact
[18:43] <wm4> but nope, got to play super-obscure audio formats efficiently
[18:44] <nevcairiel> well, there are a few audio codecs that need it because you can't really detect frame boundaries, but it could do this internally i suppose
[18:45] <nevcairiel> should potentially remove the docs from decode_video2 that say this
[18:45] <nevcairiel> not sure if it actually does a thing if you use chunked decoding
[18:45] <nevcairiel> ...which never worked right for me in the first place
[18:45] <wm4> the examples (lol) still do the partial packet video decoding
[18:45] <wm4> but mplayer, the former libav* API reference, doesn't
[18:47] <nevcairiel> not all examples
[18:47] <nevcairiel> demuxing_decoding doesnt
[18:48] <ubitux> michaelni: can you explain a bit more when it's incorrect? (re: nutenc + has_b_frames)
[18:50] <cone-693> ffmpeg.git 03Anton Khirnov 07master:321257814874: mov: export audio service type as side data
[18:50] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:6d34665c76ca: Merge commit '32125781487411ed3b1b28b32063d6cd4024d4fc'
[18:50] <ubitux> 2.6 release note is going to be awesome :)
[18:51] <nevcairiel> why
[18:52] <ubitux> there are a lot of cool things in the Changelog and incoming
[18:52] <nevcairiel> should probably add my hevc hwaccel in there
[18:52] <ubitux> yes
[18:53] <ubitux> if someone wants to review palettegen/paletteuse before it's too late, better do it now btw
[18:53] <ubitux> also, same for MOV timelines... it's kind of ready since a long time
[18:53] <ubitux> ah, and i need to finish the bc dep
[18:53] <ubitux> i guess i'll get some stuff done by the end of the week
[18:54] <michaelni> ubitux, plain violation of spec and totally breaks packet interleaving, aka ruins nut for any realtime use, as packets would be potentially several seconds mis-interleaved, it might not even play in some players
[18:55] <michaelni> thats in worst case, it wont be that bad for every file
[18:55] <ubitux> ok
[19:11] <cone-693> ffmpeg.git 03Anton Khirnov 07master:a536a4e4bc52: lavc: support extracting audio service type from side data
[19:11] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:4ce67c961c0f: Merge commit 'a536a4e4bc52d05f59869761337452fb1f1977f6'
[20:01] <cone-693> ffmpeg.git 03Vittorio Giovara 07master:7c51d79ca7ba: nsvdec: validate channels and samplerate
[20:01] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:b04cbbe25555: Merge commit '7c51d79ca7badfb370c410b8f44c9142b938e2e6'
[20:19] <cone-693> ffmpeg.git 03Vittorio Giovara 07master:e71149a7a5b1: nuv: validate image size
[20:19] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:f955abe33321: Merge commit 'e71149a7a5b10ed7baa5a06f47d0313c7bd8df52'
[20:32] <cone-693> ffmpeg.git 03Vittorio Giovara 07master:607ad990d31e: dvbsubdec: check memory allocations and propagate errors
[20:32] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:c5b6b711b291: Merge commit '607ad990d31e6be52980970e5ce8cd25ab3de812'
[20:54] <cone-693> ffmpeg.git 03Vittorio Giovara 07master:8805589b803f: libopencv: Rework error handling in parse_iplconvkernel()
[20:54] <cone-693> ffmpeg.git 03Michael Niedermayer 07master:d3d4d98764ea: Merge commit '8805589b803fab5f362008306319336ac79a3fa7'
[22:31] <cone-693> ffmpeg.git 03Reimar Döffinger 07master:d96090e7b633: Support BMP files that do not properly align lines.
[22:31] <cone-693> ffmpeg.git 03Reimar Döffinger 07master:6efd0ba977ae: swresample_internal.h: Move struct declaration before first use.
[22:58] <nevcairiel> hm, mpeg2 simple profile with nothing but P frames ... does mpeg2 use some crazy schemes like intra-refresh ? o.o
[23:26] <kierank> Nevcairiel: Yes I've seen some beforr
[23:26] <nevcairiel> apparently its a sat feed
[23:27] <nevcairiel> my code naively assumes there might be an I frame at some point, so to avoid showing too much corruption, it waits for one before showing anything
[23:27] <nevcairiel> yeah well, that didnt work out quite well!
[23:28] <kierank> There's a sample somewhere in the FFmpeg samples repo
[23:33] <llogan> at least the spammer had to take 10 tries before he succeeded.
[23:33] <llogan> usually they quit after 2 or 3
[23:34] <llogan> damned retarded though that BadContent shows them what blacklisted words they hit
[23:37] <JEEB> lol
[23:42] <llogan> oh, apparently that can be disabled somehow.
[23:44] <compn> llogan : is there a way to send these possibly spams to a moderation queue instead of them being posted ?
[23:44] <compn> much like the mailing list ?
[23:44] <compn> then we just review the spams once a week or so
[23:44] <llogan> michaelni: can you add "show_blacklisted=false" (possibly under [spam-filter]) in trac.ini?
[23:45] <llogan> compn: i doubt that would be practical. we are currently getting up to 5 per minute.
[23:46] <llogan> it's the humon spammers that are the problem though. i'd rather allow some spam in than have to wade through ham and make users wait
[23:47] <llogan> parsing the ML is boring enough
[00:00] --- Wed Jan 28 2015