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

[burek]

[00:41] <cone-611> ffmpeg.git 03James Darnley 07master:46ef45ab59e4: lavc/x86/v210: give cpuflag to INIT macro
[00:43] <jamrial> J_Darnley: did you ask the authors of those x86inc changes if they are ok with lgpl relicensing?
[00:43] <J_Darnley> Huh, that file is ISC
[00:44] <J_Darnley> I don't believe that has changed in ffmpeg
[00:45] <J_Darnley> If it has I don't think I need their permission.
[00:45] <J_Darnley> it is x86util that is gpl or lgpl (depending on which project you look at)
[00:46] <jamrial> ah true, didn't look and figured it was the same for both
[00:47] <J_Darnley> Don't worry about it.
[00:53] <cone-611> ffmpeg.git 03Michael Niedermayer 07master:467a55a4ee54: avutil/md5: workaround clang 3.5 #20849
[01:25] <cone-611> ffmpeg.git 03James Almer 07master:c3d2426cca94: x86/hevc_res_add: add ff_hevc_transform_add32_8_avx2
[01:28] <J_Darnley> Damn fork!  Stop killing my sub shells!
[01:46] <cone-611> ffmpeg.git 03Loren Merritt 07master:a4dbabc8b3c1: x86inc: free up variable name "n" in global namespace
[02:05] <cone-611> ffmpeg.git 03Henrik Gramner 07master:720c21d11ff0: x86inc: Make ym# behave the same way as xm#
[03:16] <rcombs> that file is ISC and I love it :D
[04:33] <cone-611> ffmpeg.git 03James Almer 07master:52ec81c67d11: x86/hevc_res_add: add missing guards to hevc_transform_add32_8_avx2
[04:56] <cone-611> ffmpeg.git 03Diego Biurrun 07master:d7913bf59ccb: changelog: Move Ogg subtypes aliases entry to the correct release
[04:56] <cone-611> ffmpeg.git 03Michael Niedermayer 07master:2178abd3b531: Merge commit 'd7913bf59ccbf781ce57c5d58998e8f25d10e040'
[07:45] <dahat> It seems I remain unable to successfully even configure ffmpeg to enable libx264 under MinGW and to use the the VS2013 compiler... does anyone have a functioning MinGW setup (likely with glib & pkg-config installed) that they would be willing to share so that I might make this work?  
[09:35] <tmm1> i'm using ffmpeg to do hls segmentation, and i want to be able to have it seek ahead on the input stream during transcode
[09:39] <tmm1> i'm playing with a patch to call av_seek_frame from check_keyboard_interaction() as a proof of concept, does that seem reasonable?
[09:49] <av500> you mean skip parts of the video?
[09:55] <tmm1> yea basically
[09:56] <tmm1> if the user seeks ahead in their player and requests 100.ts, i can tell the encoder to jump ahead and skip creating segments for the middle part
[09:56] <nevcairiel> you should really think about using avcodec through its API, it'll give you unlimited control over such things
[09:59] <tmm1> yea that might end up being easier
[10:10] <tmm1> hooked up seek_frame to the 'S' key and it seems to work
[10:11] <tmm1> but the segmenter uses sequential numbering still so the new frames are written to the wrong segment file
[10:59] <ubitux> http://www.anandtech.com/show/8496/dell-previews-27inch-5k-ultrasharp-monitor-5120x2880 lol
[11:00] <nevcairiel> thats brilliant
[11:01] <nevcairiel> although i have a strong dislike for MST
[11:01] <av500> awesome
[11:01] <av500> how many 80char xterms can that fit?
[11:01] <av500> with 5x7 font
[11:40] <cone-907> ffmpeg.git 03Stefano Sabatini 07master:39b517fac0b6: lavc/libvpxenc: show crf CQ value in error message
[11:41] <cone-907> ffmpeg.git 03Stefano Sabatini 07master:6f0fc1a96bd4: lavf/ffmdec: return proper error code in ffm2_read_header()
[11:41] <cone-907> ffmpeg.git 03Mark Harris 07master:ef16d1260617: doc/filters.texi: fix time duration references
[12:08] <saste> ubitux verging on the side of log nazis :-)
[12:18] <ubitux> yeah, sorry ;)
[12:21] <cone-907> ffmpeg.git 03Mika Raento 07master:b21e989a3c07: ismindex: produce .ismf file
[12:21] <cbsrobot>  ubitux: "skal" doesn't have any legal value and can cause problems in the future.
[12:21] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:0940066b8037: Merge commit 'b21e989a3c076d94cfdde0303724db841dd60cad'
[12:21] <cbsrobot> and what about the patches from wm4 ?
[12:22] <ubitux> afaik he wants to remain anonymous
[12:23] <ubitux> we knew pretty clearly the identity of skal
[12:23] <cbsrobot> personally I don't care much, but as you know sometimes it's used as an argument against ffmpeg
[12:23] <ubitux> also, this was a relicensing thing, so better get it done properly
[12:33] <cone-907> ffmpeg.git 03Pascal Massimino 07master:161fc0f46377: avfilter/x86/idet: fix license header (GPL -> LGPL)
[12:55] <cone-907> ffmpeg.git 03James Darnley 07master:db8970d7b61a: vfi/x86/vf_idet: fix incorrect use of paddq
[13:11] <cone-907> ffmpeg.git 03Benoit Fouet 07master:4f10495055ed: tiff: fix {2,4}bpp grayscale palettes.
[13:14] <saste> ubitux, my remark was more about the missing context: "lavfi/idet/x86"
[13:15] <saste> I agree that ideally we should have names in log, or that could be painful later
[13:15] <saste> good luck if you want to relicense ffmpeg
[13:15] <ubitux> :)
[13:33] <nevcairiel> good luck ever relicensing it anyway
[13:33] <nevcairiel> small modules from GPL to LGPL is one thing
[13:33] <kierank> ubitux: ianal but afaik under copyright law you have the right to anonymous contributions
[13:36] <iive> but they are not public domain.
[13:37] <kierank> of course
[13:41] <ubitux> kierank: ianal either :p
[13:44] <ubitux> http://www.cs.cmu.edu/afs/cs/project/cil/ftp/html/images/graphics/images.gif :D
[13:44] <ubitux> (from http://www.cs.cmu.edu/afs/cs/project/cil/ftp/html/v-images.html)
[14:38] <cone-907> ffmpeg.git 03Henrik Gramner 07master:428aa14a4851: x86inc: Make INIT_CPUFLAGS support an arbitrary number of cpuflags
[17:23] <ubitux> > multiple edit list entries, a/v desync might occur, patch welcome
[17:23] <ubitux> :(
[17:23] <ubitux> just hit that issue
[17:27] <ubitux> actually vlc seems to deal well with that
[17:34] <wm4> vlc has its own demuxer
[17:34] <wm4> or are they using an external lib?
[17:35] <ubitux> no idea, but it works better :p
[17:35] <ubitux> which is a shame for us :(
[17:36] <wm4> definitely
[17:39] <nevcairiel> its just that noone cared to implement it
[17:39] <nevcairiel> the usual excuse i kept hearing is "it needs playlist support"
[17:39] <nevcairiel> which i always thought is weird, why cant you just build a virtual timeline inside the demuxer
[17:40] <ubitux> where is the google patch?
[17:42] <wm4> nevcairiel: it wouldn't be inconceivable to demand that timeline stuff is done in some generic way, instead of letting each demuxer duplicate it
[17:42] <nevcairiel> except that now its never happening
[17:44] <wm4> since HLS does this already, it would be acceptable for mp4 too, I guess
[17:46] <ubitux> and soon mkv?
[17:46] <wm4> for mkv I'd demand having a callback for finding external segments
[17:47] <ubitux> we can't do it ourselves? :(
[17:47] <wm4> no
[17:48] <cone-490> ffmpeg.git 03Giorgio Vazzana 07master:d247a40aadb8: MAINTAINERS: add myself as lavd/v4l2 maintainer
[18:01] <dahat> It seems I remain unable to successfully even configure ffmpeg to enable libx264 under MinGW and to use the the VS2013 compiler... does anyone have a functioning MinGW setup (likely with glib & pkg-config installed) that they would be willing to share so that I might make this work?  
[18:35] <cone-490> ffmpeg.git 03Giorgio Vazzana 07master:39750b73641e: lavd/v4l2: Replace s1 with ctx for consistency.
[18:41] <cone-490> ffmpeg.git 03Giorgio Vazzana 07master:3da359c140a2: lavd/v4l2: simplify first_field()
[18:52] <cone-490> ffmpeg.git 03Giorgio Vazzana 07master:55cf7d9713dc: lavd/v4l2: remove unneeded variable in device_init()
[19:07] <cone-490> ffmpeg.git 03Giorgio Vazzana 07master:7865cafec295: lavd/v4l2: simplify list_framesizes()
[19:12] <ubitux> wm4: if you want me to test & apply the sub stuff, now is the time to send an update for srt
[19:13] <ubitux> libav is going to release 11 this week end (luca timeline thought), so better get it done now
[19:13] <wm4> what needs to be updated? the line reading stuff?
[19:13] <ubitux> yes
[19:13] <ubitux> invalid data is weird to the best
[19:14] <ubitux> it's not used later?
[19:14] <wm4> it's used for srt probing only
[19:14] <ubitux> ok, well then you can make it a specific function for the time being
[19:15] <cone-490> ffmpeg.git 03Diego Biurrun 07master:b574e1e97ea7: get_bits: Add OPEN_READER macro variant w/o size_plus8
[19:15] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:8c6cfffa01b2: Merge commit 'b574e1e97ea7067a5fcd3876e30a67df0e4e6611'
[19:23] <cone-490> ffmpeg.git 03Diego Biurrun 07master:096a1d5b4639: rdft: Move some variables into a separate block
[19:23] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:73aeb27cfe4e: Merge commit '096a1d5b46391f65dfd0bee6292e9962f53bd7c8'
[19:25] <wm4> ubitux: how does this look: http://sprunge.us/bQBY
[19:28] <ubitux> wm4: LGTM
[19:29] <ubitux> wm4: why did you move down the if (!c) btw?
[19:29] <cone-490> ffmpeg.git 03Diego Biurrun 07master:213e606752d1: Replace av_unused attributes by block structures
[19:29] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:1e4e760f767b: Merge commit '213e606752d16f51337e94431962fb5d7749c07e'
[19:30] <wm4> ubitux: no reason, just accidental
[19:30] <ubitux> okay
[19:31] <cone-490> ffmpeg.git 03Paul B Mahol 07master:422619646ea0: add silenceremove filter
[19:33] <cone-490> ffmpeg.git 03Paul B Mahol 07master:7bd0079e9e02: MAINTAINERS: fix typo
[20:22] <cone-490> ffmpeg.git 03Diego Biurrun 07master:2143948381c8: Drop unnecessary av_unused attributes.
[20:22] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:0a7239ae25e0: Merge commit '2143948381c8118bdc2f50bd4079520b9885bd54'
[20:41] <cone-490> ffmpeg.git 03Giorgio Vazzana 07master:0b890425e354: lavd/v4l2: simplify list_formats()
[20:57] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:4dee4a4470cd: avcodec/mpegvideo: Factor ff_mpv_decode_init() out
[20:57] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:dcb29d37d4ff: avcodec/mpegvideo: set codec tags in ff_mpv_decode_init()
[21:23] <J_Darnley> To whoever mentioned that git-send-email is sometimes a seperate package.  Thanks, it has now become one on cygwin too.
[21:24] <JEEB> yup
[21:29] <J_Darnley> Now i've forgotten what I was going to work on.
[21:41] <ubitux> wm4: do you have a ffmpeg branch somewhere? (i can git am but it seems it doesn't handle that well the vX so it's slightly painful)
[21:43] <wm4> ubitux: let me fork ffmpeg on github...
[21:44] <ubitux> if that takes you more than 5 minutes, don't worry about it
[21:46] <wm4> ubitux: https://github.com/wm4/FFmpeg/tree/patches5
[21:47] <wm4> it also has the sup patch; don't accidentally push it
[21:47] <ubitux> ok :)
[21:47] <ubitux> thanks
[21:47] <wm4> ooh
[21:47] <wm4> wait
[21:47] <kierank> wm4: https://github.com/wm4/FFmpeg/commit/a3196fb781c4a487439483fa002b30bd64bae811
[21:47] <wm4> I messed up
[21:47] <kierank> :)
[21:48] <kierank> i think i need to merge that patch
[21:48] <wm4> kierank: wow that was 1 year ago
[21:48] <wm4> ubitux: https://github.com/wm4/FFmpeg/commits/patches8
[21:49] <ubitux> ok
[22:20] <ubitux> wm4: now let's hope we don't get muxed utf-16 srt ;)
[22:21] <wm4> ubitux: assuming your player has a charset detector, this would be no problem
[22:22] <wm4> the problem with utf-16 was just that the demuxer couldn't handle it
[22:22] <ubitux> our decoders won't handle it
[22:22] <wm4> to properly handle it, you'd probably have to buffer a large number of subtitle packets...
[22:23] <wm4> because subs in 8 bit codepages can look like ASCII at first - until the first subtitle event with a special char happens
[22:54] <ubitux> erk iconv has no BOM option??
[22:59] <ubitux> wm4: are you sure about your can_seekback_2_bytes condition? shouldn't it be pb->buf_ptr - pb->buffer or i'm missing something?
[23:00] <wm4> ubitux: avio_r8 does:
[23:00] <wm4>     if (s->buf_ptr < s->buf_end)
[23:00] <wm4>         return *s->buf_ptr++;
[23:00] <wm4> so buf_ptr is the current read position
[23:01] <wm4> and buf_end the end of the valid vuffer
[23:01] <wm4> I'm not really happy with what I'm doing in the patch though... it's like playing with implementation details
[23:03] <ubitux> but isn't it about seek back? like, trying to seek if there is at least 2B between the current pos (buf_ptr) and the start of the buffer (buffer)?
[23:04] <wm4> ubitux: this is before we read these 2 bytes
[23:04] <wm4> so the code checks whether there are at least 2 bytes readable, without refilling the buffer
[23:04] <wm4> assuming that refilling the buffer makes it impossible to seek back
[23:05] <wm4> this probably works if the buffer is >= 2 bytes in size, and this is at the beginning of the stream
[23:05] <wm4> so it'll work in practice
[23:07] <ubitux> ok got it.
[23:08] <ubitux> i'm not comfortable with the avio internals so i'll leave that one out for now, even though it's useful for testing :p
[23:09] <wm4> ok
[23:09] <wm4> I don't think utf-16 files without BOM are common anyway
[23:21] <cone-490> ffmpeg.git 03wm4 07master:3e8426170ce0: avformat/assdec: UTF-16 support
[23:21] <cone-490> ffmpeg.git 03wm4 07master:d658ef18e3d1: avformat/srtdec: UTF-16 support
[23:21] <cone-490> ffmpeg.git 03wm4 07master:231a514dd3d2: avformat/samidec: UTF-16 support
[23:21] <cone-490> ffmpeg.git 03wm4 07master:b7f641dc9bff: avformat/realtextdec: UTF-16 support
[23:21] <cone-490> ffmpeg.git 03wm4 07master:c36853866712: avformat/srtdec: speed up probing
[23:21] <wm4> ubitux: nice
[23:25] <ubitux> now i need to work on getting a lena-like back in the repo
[23:31] <J_Darnley> Oh my!  Another nick used as commiter! :)
[23:31] <J_Darnley> vim main.c
[23:31] <J_Darnley> oh
[23:38] <ubitux> btw, i started looking at the rdft thing
[23:38] <ubitux> i'll try to come up with something asap
[23:39] <ubitux> (talking about #3921)
[23:39] <ubitux> anyway, 'night
[23:41] <jamrial> no tests for utf16?
[23:41] <J_Darnley> Yay, circular dependency (almost): lavfi -> my lib -> lavu
[23:43] <jamrial> it would be nice to get FATE run a round to see if some systems find corner cases before we release ffmpeg 2.4
[23:43] <J_Darnley> Wait maybe 24 hours
[23:44] <J_Darnley> I know mine runs once a day
[23:44] <nevcairiel> well if there are no tests, waiting is futile =)
[23:44] <nevcairiel> short of making sure it didnt break existing stuff
[23:44] <jamrial> that's what i mean
[23:45] <nevcairiel> dont think it was the plan to release 2.4 right now, or was it
[23:45] <jamrial> it is. libav 11 releases this weekend (supposedly)
[23:46] <nevcairiel> as if
[23:46] <nevcairiel> :D
[23:46] <nevcairiel> they want to release 12 in november, too
[23:46] <jamrial> well, considering that after uploading samples we need to wait at least one day to let every FATE slot sync them, the faster we add tests the better
[23:47] <nevcairiel> i wonder why the box doesnt just sync before running its tests
[23:47] <nevcairiel> an rsync call that doesnt have to fetch any updates shouldnt be that much of an overhead, should it
[23:48] <wm4> <nevcairiel> they want to release 12 in november, too <- hahahaha
[23:48] <wm4> also, libav 12 is supposed to break the API
[23:48] <nevcairiel> indeed
[23:48] <wm4> and 13 not
[23:49] <wm4> but I don't see how all these new developments would make it in time
[23:49] <wm4> so... 1 year to go without major bump?
[23:49] <nevcairiel> but since 11 made it into debian and ubuntu, 12 will not be in anything anyway
[23:49] <nevcairiel> if they break the api, dont they have to bump major for the release again?
[23:50] <wm4> yes
[23:52] <jamrial> how's the debian thing going for that matter? if libav was aiming to get 11 in, then they have as many chances as us getting ffmpeg 2.4 in
[23:52] <jamrial> with the whole "too close to freeze date, already tested, etc" i assumed it was libav 10 what they wanted in
[23:52] <nevcairiel> except that they have an actual debian maintainer that just adds the package without asking
[23:53] <nevcairiel> jessie has 11 now
[23:53] <nevcairiel> 11~beta1 right now
[23:58] <iive> is ffmpeg still waiting for ftp master approval?
[00:00] --- Sat Sep  6 2014