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

[burek]

[00:11:03 CET] <cone-095> ffmpeg 03Neil Birkbeck 07master:e7e5c5e6c4d7: lavf/matroskaenc.c: add early support for colour elements
[08:38:59 CET] <j-b> 'morning
[08:42:00 CET] <llogan> 'night. about to "hit the sack" as they say in English. Really, it's not as painful as it sounds.
[08:55:20 CET] <ethe> has anyone worked on reversing OptimFROG?
[09:31:57 CET] <slomo> hi! what's the official way to distinguish between libav and ffmpeg at compile time and runtime? previously i was told that ffmpeg always has LIBAVCODEC_VERSION_MICRO < 100, and libav >= 100. but that's obviously not true anymore since 3.0
[09:32:36 CET] <wm4> slomo: it's not?
[09:32:50 CET] <JEEB> I don't think there's an official way but check ffms2's configure checks
[09:33:08 CET] <wm4> the micro thing is official
[09:33:30 CET] <wm4> (as official as it could get with cranky assholes not even acknowledging the existence of Libav)
[09:33:52 CET] <wm4> slomo: also, you got it the wrong way around
[09:34:12 CET] <wm4> ffmpeg has micro versions >= 100
[09:34:22 CET] <slomo> wm4: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/version.h;h=6e42810765c3403a556a7946ace70e37e1fffe07;hb=HEAD#l32
[09:34:40 CET] <slomo> so it's actually the other way around?
[09:34:44 CET] <wm4> yes
[09:35:42 CET] <slomo> ok, thanks :)
[09:40:42 CET] <durandal_170> ethe: nope
[11:06:25 CET] <wm4> I'm really wondering what kind of shit causes code like "st->priv_pts->num != st->priv_pts->den >> 1"
[11:07:45 CET] <kierank> wm4: "Fix sample #1234"
[11:09:20 CET] <wm4> originally it was added as " fix obnoxious ogg_packet passing from encoder to muxer" in 2004
[11:10:29 CET] <wm4> hm I wonder if it'd possible to write a tool that eliminates all code from ffmpeg that doesn't change FATE results
[11:14:06 CET] <nevcairiel> if you want to get rid of all error checks, sure =p
[11:14:33 CET] <ubitux> according to coverage.ffmpeg.org you can trash 40% of the code
[11:15:31 CET] <Shiz> wm4: mutation testing!
[11:50:49 CET] <ubitux> so i'm setting hyScale and hcScale to some random function in sws, but it appears that on x86 the filtersize doesn't match the one on aarch64
[11:50:54 CET] <ubitux> any hint on the reason?
[11:51:09 CET] <nevcairiel> there is a bunch of special conditions to masage that value
[11:51:26 CET] <ubitux> where is this done?
[11:51:39 CET] <nevcairiel> somewhere in sws
[11:51:46 CET] <nevcairiel> dont expect me to remember where this spaghetti ends
[11:51:46 CET] <nevcairiel> :D
[11:52:24 CET] <ubitux> :(
[11:53:40 CET] <nevcairiel> initFilter maybe?
[11:54:09 CET] <nevcairiel> it  things like HAVE_MMX && cpu_flags & MMX in it
[11:54:36 CET] <nevcairiel> (thats in utils.c)
[11:56:31 CET] <ubitux> nevcairiel: thanks
[11:57:31 CET] <ubitux>         const int filterAlign = X86_MMX(cpu_flags)     ? 2 :
[11:57:33 CET] <ubitux>                                 PPC_ALTIVEC(cpu_flags) ? 8 : 1;
[11:57:35 CET] <ubitux> aaaah
[12:00:04 CET] <ubitux> actually, the one above, for hscale
[12:06:53 CET] <cone-229> ffmpeg 03Rostislav Pehlivanov 07master:500dc20deede: vc2enc: fix segfault
[12:06:54 CET] <cone-229> ffmpeg 03Rostislav Pehlivanov 07master:d4773c94a6b5: vc2enc: simplify count_hq_slice() and caching
[13:57:12 CET] <BBB> oh poor ubitux
[13:57:15 CET] <BBB> getting lost in sws
[13:57:29 CET] <nevcairiel> its his own fault for caring about writing sws asm
[13:58:56 CET] <ubitux> well it's fine
[13:59:04 CET] <ubitux> mostly
[14:28:52 CET] <kierank> I'm not sure accepting that mpeg-7 patch is a good idea
[14:29:07 CET] <kierank> it's a complicated academic spec and most likely the author will disappear afterwards
[14:30:07 CET] <kierank> but i guess MOAR FEATURES
[14:31:49 CET] <J_Darnley> If it was good I might support it but the guy even says that transformations will produce a different signature.
[14:33:55 CET] <wm4> hm yet another crazy mpeg thing
[14:34:24 CET] <atomnuker> I don't like adding more GPL stuff
[14:35:04 CET] Action: J_Darnley shouts "boo"
[14:37:34 CET] <nevcairiel> is that what youtube uses and why some people upload videos mirrored to avoid detection? =p
[14:54:58 CET] <Daemon404> i am fairly certain i had a prof in university, who was into MPEG-7...
[14:55:04 CET] <Daemon404> i assumed there was a reason it went nowehere
[14:55:16 CET] <Daemon404> or im rememebring some other crazy mpeg spec
[14:55:26 CET] <Daemon404> nevcairiel, youtube uses proprietary stuff
[14:56:10 CET] <Daemon404> wm4, i build ffmpeg with gcc and -O0 all the time
[14:57:11 CET] <wm4> wut
[14:57:25 CET] <Daemon404> --optflags=-O0
[14:57:27 CET] <Daemon404> builds fine
[14:57:41 CET] <nevcairiel> did you verify thats what its actually using :D
[14:57:50 CET] <Daemon404> with V=1 yea
[14:57:59 CET] <Daemon404> and it got rid of <optimized away>
[14:59:28 CET] <wm4> I guess some compilers do trivial DCE even at -O0?
[14:59:36 CET] <Daemon404> who knows
[14:59:57 CET] <nevcairiel> and some compilers fail at it even at full optimization (*cough*clang*cough*)
[15:01:09 CET] <Daemon404> yep
[15:02:05 CET] <ubitux> aren't we supposed to use --disable-optimisation?
[15:02:38 CET] <Daemon404> that doesnt use -O0 iirc
[15:02:44 CET] <Daemon404> but maybe i misremember
[15:03:28 CET] <nevcairiel> that defaults to using no -O flag iirc
[15:04:21 CET] <nevcairiel> whatever that does then
[15:11:53 CET] <ubitux> it's kinda original how the hscale x86 asm proceed to increment the width
[15:12:40 CET] <ubitux> instead of having a straightforward p[idx], it's doing sth like p_end[-w] and incrementing w
[15:12:48 CET] <ubitux> i guess it's saving a reg or sth
[15:13:00 CET] <ubitux> but damn that's confusing
[15:13:30 CET] <wm4> libswscale code is engineered to create despair
[15:14:27 CET] <ubitux> it's ok, just curious :)
[15:14:39 CET] <kierank> ubitux: that's a normal idiom, no?
[15:14:55 CET] <kierank> as much as a I like to bash swscale
[15:15:36 CET] <jamrial> ubitux: that's really common in asm
[15:15:36 CET] <J_Darnley> Yes it is.
[15:15:59 CET] <J_Darnley> Otherwise yu need to compare against width
[15:16:15 CET] <J_Darnley> or whetever your limiting value is
[15:18:07 CET] <ubitux> jamrial: in x86 maybe
[15:18:25 CET] <ubitux> but sure, ok :)
[15:18:50 CET] <ubitux> in arm you don't really need to do that
[15:29:18 CET] <wm4> so what's the right way to prevent ffmpeg from picking up winpthreads just for clock_gettime and nanosleep?
[15:29:25 CET] <wm4> on mingw
[15:30:01 CET] <Daemon404> yell at mingw?
[15:30:12 CET] <Daemon404> i hard disable winpthreads because it is crap
[15:30:25 CET] <wm4> how do you hard disable it?
[15:30:34 CET] <Daemon404> i build a toolchain without it.
[15:31:45 CET] <wm4> what makes me wonder is what makes ffmpeg link against the DLL at all
[15:31:48 CET] <wm4> is it the -lrt?
[15:33:38 CET] <michaelni> JEEB, as you are a contributor you should get voice
[15:37:12 CET] <Daemon404> context?
[15:37:44 CET] <wm4> well, my windows binaries are created with a dependency on libwinpthread.dll or something
[15:37:57 CET] <kierank> speaking of which is there a list of people with commit access
[15:38:13 CET] <Daemon404> wm4, c++ involved?
[15:38:16 CET] <wm4> (despite --enable-w32threads)
[15:38:19 CET] <wm4> no
[15:38:28 CET] <Daemon404> mingw runtime may pull it in, i dunno
[15:38:32 CET] <Daemon404> im sure they are to blame
[15:38:45 CET] <kierank> isn't libwinpthread gpl?
[15:40:27 CET] <wm4> hm actually -lrt isn't involved here
[15:42:20 CET] <jamrial> wm4: are you using msys2's mingw package?
[15:42:36 CET] <jamrial> or a toolchain like the one nevcairiel built?
[15:42:39 CET] Action: Daemon404 plays around with mmap
[15:43:10 CET] <jamrial> the former has a billion shared libraries and some depend on winpthreads, even if you compile ffmpeg using w32threads
[15:43:35 CET] <jamrial> so you're better using a static toolchain like nev's if you want a portable ffmpeg binary
[15:46:52 CET] <kierank> Daemon404: are you doing mmap on an fd?
[15:46:55 CET] <kierank> and then just seeking?
[15:47:03 CET] <kierank> "seeking"
[15:47:37 CET] <Daemon404> writing all over the place
[15:47:50 CET] <Daemon404> it's just a test program
[15:47:52 CET] <kierank> it's the right way to do it
[15:48:12 CET] <kierank> I remember virtualdub had a hex editor inbuilt
[15:48:58 CET] <Daemon404> this isnt for my compare tool :P
[15:49:38 CET] Action: durandal_170 uses dhex
[15:50:19 CET] <Daemon404> last time i checked, dhex could not handle comparing files with inserted/deleted bytes
[15:50:26 CET] <Daemon404> also it crashed a lot
[15:51:07 CET] <durandal_170> fix it, its open source
[15:52:34 CET] <Daemon404> it's code is uh... eye-bleeding
[15:52:37 CET] <Daemon404> its~
[15:58:17 CET] <durandal_170> so your version is gonna be closed source?
[15:58:43 CET] <Daemon404> ... wut?
[15:59:53 CET] <durandal_170> Why we don't have dshow wrapper?
[16:17:03 CET] <nevcairiel> wm4: as the others have said, its likely a transient dep pulled in from some other mingw crap
[16:17:24 CET] <nevcairiel> dont use the msys2 toolchain for portable builds
[16:18:48 CET] <wm4> what then
[16:19:36 CET] <nevcairiel> use mine if you want, https://files.1f0.de/mingw/ .. or any other static toolchain from around the web which are probably build in a similar manner
[17:46:13 CET] <JEEB> michaelni: so should I re-post 3/3 with the updated hash?
[18:28:58 CET] <michaelni> JEEB, hmm, probably yes
[18:29:05 CET] <JEEB> ok
[18:29:22 CET] <JEEB> will try to run the tests at home
[18:30:12 CET] <JEEB> also when I have the time I'll have to see if I can get negative cts offsets implemented
[18:30:52 CET] <JEEB> i have a poc patch for it but it doesn't work
[18:31:59 CET] <michaelni> ok
[18:32:54 CET] <JEEB> that way cts = dts for the first sample
[18:33:17 CET] <JEEB> which is what cases without edit lists require
[18:33:35 CET] <JEEB> (fragmented stuff, dash, mss)
[18:34:16 CET] <JEEB> i guess for vod you can have an edit list
[18:34:28 CET] <JEEB> live is where you can't, though
[18:43:43 CET] <wbs> JEEB: no, you can have an edit list for live just fine
[18:43:59 CET] <wbs> it's only in smooth streaming where it isn't actually transmitted at all
[18:45:38 CET] <JEEB> wbs: ah ok
[18:46:21 CET] <JEEB> DASH livestream with edit lists would be funky I guess
[18:54:38 CET] <wbs> not really
[18:54:53 CET] <wbs> if you understand the way the isom timestamps work
[18:55:02 CET] <JEEB> funky as in "I wonder how many implementations would understand it"
[18:55:10 CET] <wbs> ah, yes, that's probably quite true :P
[18:55:44 CET] <JEEB> technically it makes sense, if you have edit lists for each fragment or so (because live streams generally don't have a limited duration)
[18:55:53 CET] <JEEB> and it would make some stuff heckuva lot simpler
[18:56:20 CET] <wbs> it's not per fragment, but just one at the start
[18:56:24 CET] <JEEB> hmm
[18:56:29 CET] <JEEB> so duration can be eternal or whatever?
[18:56:49 CET] <wbs> yes, in 14496-12:2012, there was an amendment that allowed that
[18:56:52 CET] <JEEB> cool
[18:57:02 CET] <wbs> before that it didn't work, true
[18:57:07 CET] <JEEB> that's actually applaudable
[18:57:24 CET] <wbs> yes, the 2012 revision fixed all the issues I had wrt streaming
[18:57:46 CET] <JEEB> meanwhile DASH IF and other things are seemingly trying to get through without edit lists as far as they can
[18:57:47 CET] <wbs> the same thing about non-absolute offsets in tfhd
[18:58:06 CET] <wbs> probably because nobody understands the isom timetamp model :P
[18:58:15 CET] <JEEB> indeed
[19:49:37 CET] <TD-Linux> and no one cares about A/V sync
[19:49:58 CET] <TD-Linux> or having an audio track that is the correct length for that matter
[19:51:36 CET] <michaelni> TD-Linux, i do care about a/v sync
[19:51:52 CET] <fritsch> we also do
[19:51:55 CET] <fritsch> :-)
[19:52:46 CET] <TD-Linux> unfortunately that also requires cooperation of the people who make the DASH streams :)
[19:53:46 CET] <kierank> not many people care about sample level sync like I do
[19:55:45 CET] <JEEB> I'm actually not sure how you'd do encoder delay with live DASH with negative CTS offsets... you have the same fragment start timestamp as video, and then all samples have a negative CTS offset and you just have a bit more samples in the fragment?
[19:56:08 CET] <JEEB> or do you actually use a fragment DTS that is smaller than the one in video accordingly, and have no CTS offsets
[19:57:10 CET] <fritsch> we had the biggest issues with reconfiguring our renderer
[19:57:15 CET] <fritsch> on stream changes
[19:57:35 CET] <fritsch> to not have visual impact - in kodi we implemented it via a binary addon interface and an inputstream.mpd addon
[20:51:46 CET] <D`K_C> Hi guys, is that normal that libavformat/avio.h does not include libavformat/url.h (where struct URLContext is defined)?
[20:52:07 CET] <wm4> yes
[20:53:37 CET] <D`K_C> what is the reason for that?
[20:53:50 CET] <wm4> the URL stuff is private API
[20:53:56 CET] <wm4> while avio.h is a public header
[21:00:35 CET] <Daemon404> bugs that arent ffmpeg. cool.
[21:00:55 CET] <JEEB> lol
[21:04:13 CET] <D`K_C> ho right, the application is using the private API...
[21:05:10 CET] <D`K_C> thanks wm4
[21:14:23 CET] <cone-127> ffmpeg 03Michael Niedermayer 07master:6e65b9bb1f55: avformat/utils: scan a bit farther for a keyframe in mpeg/mpegts (7 sec instead of 5, we already scan 90sec in some cases by default)
[22:44:58 CET] <yashpatel> michaelni: Sir, what is the reason for using these specific 5 contexts as mentioned in 'http://www.ffmpeg.org/~michael/ffv1.html#context'. Are these derived  from some experimental values or there goes some theory behind choosing them ? Bcs as in JPEG-LS different contexts are chosen. My question is how to know which contexts to choose ?
[23:06:12 CET] <michaelni> yashpatel, the reason is rather boring, "it worked well"
[23:07:19 CET] <yashpatel> michaelni: Sir, I've been reading a lot of content regarding the same. Could you please guide me as to how can I improve the algorithm, as mostly things seem to be based on experimental results.
[23:08:55 CET] <TD-Linux> doing experiments is pretty much the only way to do it
[23:09:13 CET] <TD-Linux> because ffv1 is lossless, the experiments are pretty easy - compress a lot of video and look at the output size
[23:09:29 CET] <TD-Linux> you can get a collection of videos to compress here https://media.xiph.org/video/derf/
[23:18:02 CET] <michaelni> yashpatel, if i knew of a certain and simple way to improve it, i would already have improved it. But its certain there are improvments possible, it could b from small changes, from replacing some part by a different better implementation, or from some additional layer that performs further decorrelation, or ...
[23:19:40 CET] <michaelni> this problem is rather similar to implementing good P frame compression, that too will need stepwise "improving" and alot of testing various ideas ...
[23:25:12 CET] <atomnuker> started doing some experiments for an ffa1 codec: https://github.com/atomnuker/FFmpeg-FFA1
[23:27:46 CET] <J_Darnley> Neat!
[23:28:39 CET] <J_Darnley> Wait, was it you talking about over-engineering an audio codec or someone else?
[23:29:15 CET] <cehoyos> michaelni: A user has finally uploaded a "motion jpeg 2000" sample meaning concatenated j2k samples. Would a j2k parser be a valid enhancement request?
[23:29:28 CET] <cehoyos> ... concatenated j2k frames, sorry
[23:39:28 CET] <atomnuker> J_Darnley: might have been me, overengineering stuff is the greatest!
[23:39:42 CET] <J_Darnley> :)
[23:42:42 CET] <wm4> what would ffa1 have that dozens of lossless codecs don't already have
[23:43:47 CET] <nevcairiel> more alien technology powering its algorithms
[23:47:22 CET] <atomnuker> will not follow the LPC + golomb/rice residuals convention
[23:48:25 CET] <atomnuker> which already makes it dissimilar to almost everything else
[23:48:48 CET] <atomnuker> monkey's audio is different to most other codecs but it still sucks
[23:49:38 CET] <nevcairiel> the dalaa entropy coding looks extremely convoluted though, not sure thats going to find many people being fans of =p
[23:50:12 CET] <atomnuker> I'm a fan of it and that's enough
[23:50:55 CET] <atomnuker> if I don't get much better results than flac I'll scrap it
[23:52:37 CET] <michaelni> cehoyos, probably yes, possibly the mjpeg parser could be resued, not sure, one would eed to compare the structure
[23:53:12 CET] <michaelni> atomnuker, ffa1 <-- very cool idea
[00:00:00 CET] --- Tue Mar 22 2016