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

[burek]

[02:24] <cone-54> ffmpeg.git 03Michael Niedermayer 07master:5145d22b88b9: avcodec/diracdec: Tighter checks on CODEBLOCKS_X/Y
[02:24] <cone-54> ffmpeg.git 03Michael Niedermayer 07master:39680caceebf: avcodec/dirac_arith: fix integer overflow
[08:51] <cehoyos> Compn: The xcb options have to be identical, it is supposed to be a drop-in replacement.
[08:51] <cehoyos> The pts code was "reimplemented".
[08:52] <cehoyos> (I am of course very grateful that you see my point about what they really are but in this case their point can at least be argued.)
[09:42] <ubitux> are we really putting back the daemon mode?
[09:42] <ubitux> (in ffserver)
[09:42] <ubitux> is it really up to ffserver to do that?
[09:43] <ubitux> looks like something that could be handled with any decent service manager, in a probably way more reliable way 
[09:44] <arwa> I am getting this error  - " rsync: failed to connect to fate-suite.ffmpeg.org (192.190.173.45): Connection refused (111) " when I am running this command - " make fate-rsync SAMPLES=fate-suite/ ".
[09:44] <arwa> what should I do?
[09:45] <ubitux> you're like at least the 3rd opw student complaining about this
[09:46] <ubitux> is there a great wall of india or something?
[09:46] <ubitux> what kind of network are you on?
[09:47] <arwa> hahhahahaa :p
[09:47] <ubitux> ask your sysadmin to open the necessary ports or whatever
[09:47] <arwa> I am behind a proxy....do i need to configure the proxy settings to access this?
[09:48] <ubitux> yes
[09:51] <ubitux> wm4: https://trac.ffmpeg.org/ticket/4059
[09:53] <wm4> man nicolas
[09:53] <wm4> didn't he argue all the fucking time support for encoding should always done at the demuxer level
[09:56] <ubitux> oh come on 
[09:57] <wm4> come on what
[09:57] <wm4> Matroska packets are also in utf-8
[09:57] <ubitux> haha this is so stupid
[09:57] <wm4> so much for his "consistency"
[09:57] <ubitux> i mean your insults :p
[09:58] <wm4> his comments make no sense, he just saw that I wrote utf-16 support, so it was obviously Wrong in his view
[09:58] <ubitux> cehoyos: maybe a proper fix involves changing the avctx->sub_charenc_mode
[09:58] <ubitux> into these decoders
[09:58] <ubitux> or something along these lines
[09:59] <wm4> "Support for UTF-16 in text files was added savagely at the demuxer level,"
[09:59] <wm4> "savagely"
[09:59] <ubitux> :D
[09:59] <wm4> and HE argued all the time that all encodings should be handled at the demuxer level
[09:59] <ubitux> i don't exactly remember what was the exact purpose of sub_charenc_mode but i believe he wanted to use that
[09:59] <ubitux> but i'll let you two fight over this
[09:59] <wm4> so he didn't care about fucking over the API completely
[10:00] <wm4> anyway, fucking retard.
[10:00] <ubitux> ah seems nicolas suggested the same thing
[10:00] <wm4> not to mention that the patch was in review for 6 months
[10:00] <ubitux> :)
[10:04] <wm4> nicolas' complaint is that his shitty code boils down to corrupting utf-8 input
[10:05] <cehoyos> ubitux: Sorry if I misunderstand but I thought I am the one suggesting the hacks?
[10:05] <cehoyos> Do you mean that the demuxer should overwrite the user's option?
[10:05] <ubitux> i don't know
[10:06] <cehoyos> I'll commit the warning later, it will fix the user's case, if anybody has a real fix, I'll be very happy about it!
[10:06] <ubitux> the sub_charenc design nicolas asked me to follow when i added it is still kind of obscure to me
[10:07] <ubitux> but it looks like it was in that spirit, and it seems that's what nicolas is suggesting as well
[10:15] <wm4> IMO it would be fine to ignore the user's settings if the subtitles are known to be in utf-8 and no force mode is specified (such a mode would have to be added)
[10:15] <wm4> or it could just not corrupt valid utf-8, unless you want to cater to the odd use-case of fixing double-encoded utf-8 or something
[10:16] <thardin> I ý unicode
[10:17] Action: ubitux wonders if that fail was on purpose
[10:18] <ubitux> wm4: well, if it's set on automatic, your detection should take over it
[10:19] <ubitux> but since it's talking about libavcodec etc
[10:19] <ubitux> i really don't know how that's suppose to be deal with
[10:19] <thardin> ubitux: I'm alluding to this: http://seriot.ch/resources/talks_papers/i_love_unicode_softshake.pdf
[10:20] <ubitux> alright ;)
[10:20] <wm4> I also think these details should not be handled in libavcodec
[10:20] <wm4> but ffmpeg.c, or a helper function
[10:20] <wm4> libavcodec is not the fucking userinterface
[10:20] <wm4> even if ffmpeg.c seems to think so
[10:27] <J_Darnley> "double-encoded utf-8" wat
[10:28] <ubitux> this pdf is really cool thardin 
[10:28] <ubitux> i like the last pages dedicated to all kind of stuff broken on osx
[10:31] <thardin> but osx does have the beer mug emoji
[10:32] <ubitux> can you use it in a filename?
[10:32] <thardin> of course
[10:32] <thardin> a coworker of mine uses it instead of $ at the end of his terminal line on fridays
[10:32] <thardin> like "use at machine~[beer mug] echo woo, friday!"
[10:34] <J_Darnley> :) neat
[10:35] <J_Darnley> But I frown upon that horrible bit of unicode.
[10:36] <Kovensky> 🍺 🍻
[11:04] <cone-768> ffmpeg.git 03Rémi Denis-Courmont 07master:26ab504ad8d2: vdpau/h264: request MAIN rather than BASELINE VDPAU profile for CBP
[11:04] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:ab9ba8887705: Merge commit '26ab504ad8d2b23535c9a0ad43bf1fd0e6aa0893'
[11:06] <Daemon404> beer mug emoji eh 🍺
[11:13] <thardin> 
[11:15] <thardin> unicode related libraries should have names outside US-ASCII
[11:15] <nevcairiel> but then you would need the library to read the library name, which you dont have at that point!
[11:15] <thardin> -lŒuoT1
[11:15] <cone-768> ffmpeg.git 03Rémi Denis-Courmont 07master:ce91b2eae6ea: vdpau: return MAIN instead of BASELINE for H.264 CBP
[11:16] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:dd5123a04c67: Merge commit 'ce91b2eae6ea52fc1a7003566d26db20ca62d745'
[11:29] <cone-768> ffmpeg.git 03Anton Khirnov 07master:4ad1eba01186: lavd: fix building x11grab after a6674d2
[11:29] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:c2e995674fc2: Merge commit '4ad1eba011860224831ce0bb3123f6f55716b68a'
[11:48] <thardin> what do I need to have installed to make ffplay again?
[11:48] <nevcairiel> sdl
[11:49] <thardin> I tried installing libsdl2-dev and reconfiguring. no dice
[11:51] <iive> sdl1, afaik
[11:52] <thardin> libsdl1.2-dev
[11:56] <cehoyos> You need sdl-config in your path.
[11:57] <cehoyos> Or check_pkg_config sdl has to succeed.
[11:57] <cehoyos> "pkg-config --exists --print-errors sdl"
[11:58] <cehoyos> "sdl-config --version"
[11:58] <cehoyos> One of them has to succeed
[11:58] <cehoyos> For more info, search for "check_pkg_config sdl" in config.log
[12:00] <thardin> it works
[12:00] <thardin> working on a patch for tickets 4040 and 3278
[12:01] <wm4> reading that unicode doc
[12:01] <wm4> they seriously suggest using wchar_t over char?
[12:02] <thardin> they probably have their reasons
[12:02] <cehoyos> thardin: The patch will be much appreciated!
[12:03] <thardin> glad to see the avc-intra patch looking much nicer too
[12:03] <wm4> wchar_t does not need to have anything to do with unicode
[12:03] <wm4> it was created for ancient multibyte non-sense
[12:04] <wm4> like shift-jis and what not
[12:06] <cehoyos> https://trac.ffmpeg.org/query?status=!closed&keywords=~mxf shows one or two more issues: Do you have a possibility to test if the file from ticket 3624 is valid?
[12:07] <rcombs> wm4: I think they're confusing C/C++ best practices for Windows best practices
[12:08] <wm4> that must be the reason
[12:08] <wm4> but windows uses utf-16 for wchar_t
[12:08] <wm4> which is not ideal at all
[12:30] <rcombs> <wm4> but Windows is not ideal at all <-- FTFY
[12:39] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:280da99a8fdd: avdevice/xcbgrab: set avclass category
[12:39] <cone-768> ffmpeg.git 03Christophe Gisquet 07master:4fa772acbbac: dv: increase VLC reading bits to 10
[12:57] <cone-768> ffmpeg.git 03Christophe Gisquet 07master:beb944786e62: dvenc: mark encoder as intra
[14:02] <kierank> http://obe.tv/about-us/obe-blog/item/19-fosdem-call-for-participation
[14:02] <kierank> spam
[14:02] <kierank> anyway please submit stuff to the fosdem media track
[14:42] <thardin> are the samples at http://samples.ffmpeg.org/ffmpeg-bugs/  part of FATE?
[14:46] <cehoyos> thardin: How would that be possible?
[14:46] <cehoyos> The directory contains several G iirc
[14:46] <cehoyos> And not all samples can be decoded bit-exact
[14:47] <cehoyos> (I am not arguing we shouldn't create a testcase for every fixed bugs but this means a lot of work and we haven't done it so far.)
[14:47] <thardin> I feel like there should be some test that goes "well, it shouldn't crash or hang on these files"
[14:48] <cehoyos> Around 38GB
[14:48] <thardin> maybe not FATE, but something
[14:48] <cehoyos> As said, I don't disagree.
[14:48] <cehoyos> It's just (as I regularly write on ffmpeg-user) that time is the only limiting factor.
[14:48] <thardin> something to run before each release
[14:48] <thardin> ic
[14:48] <cehoyos> Do you know of a hang or crash regression?
[14:49] <cehoyos> ... only limiting factor for FFmpeg development.
[14:49] <thardin> I'm working on http://trac.ffmpeg.org/ticket/3278 and http://trac.ffmpeg.org/ticket/4040
[14:49] <thardin> and I changed a byte in 3278 to demonstrate a tricky case in my patch
[14:49] <cehoyos> I know, 3278 is not a regression and 4040 neither hangs nor crashes.
[14:50] <cehoyos> I mean: not a current regression
[14:50] <thardin> it strikes me that the commit that reverts the hack for 3278 should probablt go after the proper fix
[15:38] <thardin> cehoyos, michaelni: patches submitted to ML
[15:40] <thardin> I'm slowly getting the feeling that the backward parsing should be made into its own loop instead of being mixed in with the old code
[15:44] <wm4> why does mxf require backwards parsing?
[15:44] <wm4> morbid curiosity here
[15:45] <thardin> because you need to find all partitions
[15:46] <Daemon404> ... don't people stream mxf too
[15:46] <thardin> each partition points to the last one, and there's the Random Index Pack at the end which tells the position of each partition
[15:46] <Daemon404> that soudns pervers.e
[15:46] <thardin> yeah, it's so you can stream it to tape
[15:46] <wm4> lol
[15:46] <Daemon404> i see
[15:46] <Daemon404> that sounds perverse, as i said
[15:46] <thardin> there's nothing in the partition pack that tells where the *next* partition is
[15:47] <thardin> so the demuxer goes "read RIP (if any), parse headerpartition, then the first body partition, then seek to footer partition and parse each PreviousPartition from it until you get back to the first body partition"
[15:48] <thardin> then figure out where the essence is in each of those partitions
[15:48] <thardin> then curl up in a corner and cry
[15:48] <Daemon404> so in a truly streamign situation, you need to keep a buffer available... and there is no guarantee it will be a big enough buffer?
[15:48] <nevcairiel> if you have the RIP, do you still need the backwards parsing?
[15:48] <thardin> there's no need for any buffer
[15:48] <thardin> nevcairiel: no, but there's no reason not to parse backward
[15:48] <Daemon404> thardin, how would you do backwards parsing then
[15:49] <Daemon404> if you can only read more byets
[15:49] <Daemon404> bytes
[15:49] <Daemon404> wothout buffered i/o i mena
[15:49] <thardin> you gain nothing from not parsing backward. you still need to seek and parse each partition pack
[15:49] <nevcairiel> if you dont need random access, you probably dont need to find all partitions right away?
[15:49] <thardin> exactly
[15:49] <Daemon404> ah ok
[15:49] <Compn> cehoyos : a drop in replacement is fine, but why are the strings/description of the options identical ?
[15:49] <thardin> that reminds me, I need to make sure mxfdec.c still works on a pipe
[15:50] <thardin> yep
[15:51] <thardin> I think there's still a few pathological cases where mxfdec will end up taking O(N²) time to parse a file
[15:51] <cehoyos> Compn: Because they were copied.
[15:51] <cehoyos> As said, I am happy that you see my point now.
[15:52] <Compn> ive seen your point from the beginning :P
[15:53] <Compn> i think i've pointed out attribution before
[15:54] <cehoyos> There are many crystal-clear copyright violations in avconv, I don't think copying an option table and helplessly refactoring some timestamp code is particularly worrisome.
[15:55] <Compn> well i'd like to resolve them in ffmpeg :P
[15:55] <Compn> ehe
[15:57] <Daemon404> gi/g 42
[15:57] <cehoyos> I am not sure there is anything to resolve: The original authors of the table all have agreed several times to the relicensing of their code to LGPL and they have not requested a copyright note in the file header.
[15:57] <cehoyos> Good luck with trying to rewrite the pts code (a second time)!
[15:58] <Compn> oh ok :P
[15:58] <Compn> i forgot to take that into account lol
[16:01] <cehoyos> But if it makes you feel better add a comment to the options table with the name of the authors - the copying was done so crudely that git blame -M -C does not help;-(
[16:02] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:e70312dfc22c: avcodec/dxa: check dimensions
[17:52] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:86e574928536: avformat/mvdec: Check size for validity in var_read_string()
[17:52] <cone-768> ffmpeg.git 03Michael Niedermayer 07master:f1c21a200bcb: avformat/mvdec: Check size in read_table() for validity
[18:27] <saste> ubitux: do you know the xBR original code?
[18:28] <saste> because I see we have a 16MiB rgb2yuv table in the port
[18:29] <wm4> 64 mib
[18:31] <saste> could we use some shared table in lsws?
[18:33] <michaelni> why doesnt it use the 3 lines of code to do rgb->yuv or call sws to turn the whole image into yuv or am i missing something ?
[19:05] <ubitux> michaelni: i tried to inline the rgb2yuv convert in the function without a LUT
[19:05] <ubitux> and it's a bit slower here
[19:05] <ubitux> probably due to the /1000
[19:06] <ubitux> i tried to replace it with a shift but it's not exact with the refrence anymore, and it definitely affects visibly the output
[19:06] <ubitux> the "xBR original code" for that part is supposed to be the same as HQx
[19:06] <ubitux> for the rest i don't know
[19:07] <ubitux> going to reply on the ml
[19:11] <cone-768> ffmpeg.git 03Tomas Härdin 07master:fc1b89d887a5: mxfdec: Break out parts of mxf_read_header() into separate functions
[19:11] <cone-768> ffmpeg.git 03Tomas Härdin 07master:37c36861550f: mxfdec: Parse PreviousPartition in mxf_seek_to_previous_partition()
[19:11] <cone-768> ffmpeg.git 03Tomas Härdin 07master:1b17b64ee4d6: Revert "avformat/mxfdec: detect loops during header parsing"
[19:11] <cone-768> ffmpeg.git 03Tomas Härdin 07master:b83affdc94a9: mxfdec: Merge last_partition and footer_partition
[19:11] <cone-768> ffmpeg.git 03Tomas Härdin 07master:1a25c336aaaf: mxfdec: Tighten RIP length bounds in mxf_read_random_index_pack()
[19:20] <ubitux> btw, if people think the performance impact is not important in comparison to the memory usage, i'm fine changing it
[19:20] <ubitux> (regarding hqx lut)
[19:21] <ubitux> now it might be interesting to check the asm sources of hqx
[19:21] <ubitux> (the original ones)
[19:21] <ubitux> and check if it wasn't doing this inaccuracy as well
[19:21] <ubitux> in which case i would agree to change that
[19:32] <jamrial> ubitux: how about adding both, and compile one or the other depending on CONFIG_SMALL?
[19:37] <ubitux> isn't CONFIG_SMALL about the binary size?
[19:40] <jamrial> i've seen it used also for memory usage
[19:42] <ubitux> mmh
[19:42] <ubitux> i just checked the original hqx sources
[19:43] <ubitux> and it seems to be bitexact
[19:43] <ubitux> so i can probably just adjust to it
[19:52] <ubitux> and the original code was supporting only rgb565
[19:52] <ubitux> or something like that
[19:52] <ubitux> alright i guess i'm going to change that
[20:13] <ubitux>     Y = (r + g + b) >> 2;
[20:13] <ubitux>     u = 128 + ((r - b) >> 2);
[20:13] <ubitux>     v = 128 + ((-r + 2*g -b)>>3);
[20:13] <ubitux> meh.
[20:26] <Daemon404> mmm mm
[20:57] <amalia> michaelni I have installed Virtual box on my Fedora 20 host OS
[20:58] <amalia> I installed a guest OS - Scientific Linux 6.4 and have tried variously to compile ffmpeg on it
[20:58] <amalia> I install necessary dependencies like vpx, lame, etc. 
[21:01] <amalia> The compilation of ffmpeg takes like 30 minutes and leads to a fatal error when compiling a certain tagean.o file. So can't proceed with the make install and make distclean
[21:03] <amalia> michaelni. Can I run the FATE tests on my Fedora host for now given that it is not on the list
[21:03] <amalia> ?
[21:06] <michaelni> is that a multi core CPU ?
[21:06] <michaelni> 30min seem a bit long
[21:08] <michaelni> also did compile run quicker on the host than the virtualboxed guest ?
[21:08] <michaelni> also what is the exact error 
[21:09] <amalia> yeah it is a multi core CPU
[21:09] <amalia> I did not try compiling on the host
[21:09] <amalia> michaelni. Can I run the FATE tests on my Fedora host for now given that it is not on the list ?
[21:10] <michaelni> are the multiple cores available to the guest os ?
[21:10] <amalia> The ffmpeg compilation froze the guest OS and I couldn't retrive it
[21:10] <michaelni> virtualbox (settings->System->Processor) allows to adjust the number of cores available
[21:10] <amalia> I don't think there are multiple cores available for the guest
[21:13] <michaelni> is the host running stable or it crashes and hangs too occasionally ?
[21:14] <amalia> The host runs stably
[21:15] <amalia> Was thinking of running the FATE test on the Fedora 20 host and submitting the results before continuiing to dabble with the guest OSs on Virtual box
[21:15] <amalia> Don't know if this is okay for now
[21:17] <michaelni> what version of virtualbox is that ?
[21:17] <amalia> 4.3.18
[21:18] <michaelni> well, sure you can setup a fate client on the host if you like but we need to get something in some OS working in a virtualbox
[21:22] <michaelni> amalia, also try to access/use the guest via ssh not the GUI of the guest, might be that theres some display driver issue in the guest or host
[21:24] <michaelni> amalia, you can also ask on some virtualbox forum or irc channel about the scientific linux freeze, maybe someone there has a idea
[21:25] <amalia> Okay
[21:28] <ubitux> (note: even with the bithack, it seems slower than the lut)
[21:33] <michaelni> amalia, also use confiure with --optflags=-O1 and if you dont need debuging --disable-debug that will cut build time down to half or so
[21:34] <michaelni> and ccache should help if you build multiple times
[21:34] <michaelni> with --cc='ccache gcc'
[21:34] <amalia> Thanks michaelni. That's more comforting
[22:03] <amalia> michaelni I just compiled ffmpeg on the fedora 20 host. How do I run the FATE tests ? Any links ?
[22:05] <kasper93> https://www.ffmpeg.org/fate.html
[22:09] <amalia> kasper93 I get this http://paste.kde.org/pmjqxtzfu
[22:10] <amalia> Wich directory is the top-level source directory ? ffmpeg_sources or ffmpeg/ ?
[22:20] <kasper93> ./configure --samples=fate-suite/
[22:20] <kasper93> make fate-rsync
[22:20] <kasper93> make fate
[22:21] <kasper93> "make fate-rsync SAMPLES=fate-suite/" this one indeed doesn't work. 
[22:21] <llogan> amalia: ffmpeg_sources is not in the ffmpeg source. is it a directory you created?
[22:22] <amalia> I think my source is in ffmpeg
[22:23] <kasper93> yeah, directory is ok, just wrong command.
[22:23] <amalia> llorgan ffmpeg/ is in ffmpeg_sources
[22:26] <amalia> kasper93 Much better result after running the ./config command http://paste.kde.org/pz7dkuuqx
[22:50] <amalia> Do the tests always take this long ?
[22:52] <Daemon404> you could run several at once with make -jN, where N is # of cores
[22:52] <michaelni> amalia, here are some benchmarks: https://trac.ffmpeg.org/wiki/CompileBenchmarks
[22:52] <michaelni> and yes use -jN
[22:52] <amalia> Okay thanks
[22:55] <wm4> interesting numbers
[22:55] <wm4> so disabling compiler optimizations is much worse for fate than disabling almost all asm
[22:55] <nevcairiel> disable-optimizations only goes to O1, doesn't it?
[22:56] <ubitux> someone seems derping with a blackberry
[22:57] <nevcairiel> hm nah guess it uses whatever is gcc default, it doesnt set any -O
[22:58] Action: Daemon404 likes [FFmpeg-devel] new encoder function(urgent)
[22:58] <wm4> it still got to do DCE
[23:01] <wm4> apple started a trend with their "sent from my expensive piece of shit status symbol" message, huh
[23:06] <kierank> Daemon404: yeah that made me lulz
[23:06] Action: llogan likes that he also sent "new encoder function(urgent)" to libav-user, -devel, and -user
[23:06] <llogan> with multiples sitting in mod queue
[23:07] <llogan> he is from India. of course it's urgent.
[23:08] <ubitux> wtf is that mike doing...
[23:08] <llogan> ubitux: i set the "mod bit" to his account.
[23:08] <kierank> llogan: it's a opw student, no?
[23:08] <llogan> i don't know.
[23:10] <llogan> kierank: looks like you're right. she I guess then.
[00:00] --- Wed Oct 29 2014