[00:06] <cone-682> ffmpeg.git 03Stefano Sabatini 07master:5e1c57f5cb4e: ffplay: do not call avcodec_register_all() explicitly [02:05] <cone-682> ffmpeg.git 03James Almer 07master:eff2edae5620: Partially revert "Merge commit 'f187557ab4612776f7f527ecf3d40062975c3e4c'" [02:29] <cone-682> ffmpeg.git 03Hendrik Leppkes 07master:841c0aafa570: avcodec/pthread: check packet buffer allocation [08:43] <clever> BBB: still about? [09:19] <ubitux> BBB: sure, feel free to share current state :) [09:22] <clever> trying to add omx directly to ffmpeg now [09:22] <clever> but i need to add -I flags to the build, and dont see an obvious place to modify configure [09:22] <ubitux> as a target? [09:23] <clever> so whenever you build against the rpi, it adds 3 folders to -I [09:23] <clever> right now, i'm having to manualy edit config.mak [09:24] <ubitux> what's the -I you need to add? [09:24] <clever> -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include [09:24] <ubitux> what's this? [09:24] <clever> the headers required for gpu decode on the rpi [09:24] <ubitux> what distributes this? [09:25] <clever> they are usualy pre-installed on any rpi distro image [09:25] <ubitux> in that place? [09:25] <clever> yep [09:25] <clever> always at that location [09:25] <clever> but you can also download them from https://github.com/raspberrypi/firmware/tree/master/opt [09:25] <ubitux> do you have a tool to get those path? [09:25] <ubitux> like pkg-config --cflags vc [09:25] <ubitux> or something [09:25] <clever> pkgconfig hasnt been setup yet [09:26] <clever> one of the many things its missing [09:26] <ubitux> mmh [09:26] <clever> i was thinking just check to see if /opt/vc exists, and add a --enable-rpi or --disable-rpi flag [09:26] <ubitux> well in that case you could just --extra-cflags='-I...' [09:27] <clever> but it needs 3 seperate directories, and it would be simpler for the end user to roll it all into a single flag [09:27] <clever> rather then make them hunt down the crazy mess every time [09:27] <ubitux> yes but ppl are likely to put them in different places [09:27] <clever> the paths within /opt/vc/ are always the same [09:28] <ubitux> since no one except you is going to compile on the rpi directly :p [09:28] <clever> and thats where the sysroot cross compile options come into play [09:28] <clever> $sysroot/opt/vc [09:28] <clever> if you dont supply that, it just evals to /opt/vc/ [09:30] <ubitux> well, maybe look for "toolchain" [09:30] <ubitux> in the configure [09:30] <ubitux> but i'm not sure that's a good idea [09:30] <clever> i think thats something a bit different [09:30] <ubitux> we have valgrind in the toolchain [09:31] <ubitux> just add a case here for now [09:31] <ubitux> don't bother too much on this for now [09:34] <ubitux> you also have the target_os thing [09:34] <clever> but the os is simply linux based [09:34] <ubitux> but the rpi has multiple os so& [09:35] <clever> doesnt feel like the right option [09:35] <ubitux> indeed [09:35] <ubitux> --extra-cflags and here you go [09:35] <ubitux> you just add the documentation in platform.texi [09:35] <ubitux> so ppl can copy paste [09:35] <ubitux> and adjust if necessary [09:36] <clever> root@pi2:~# pkg-config rpi --cflags [09:36] <clever> -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include [09:36] <clever> or just make my own pkg-config file and send them a pull request later [09:36] <clever> now how do i make configure use this pkg-config file? [09:37] <ubitux> hehe :) [09:37] <ubitux> look for require_pkg_config [09:37] <clever> ah, that looks like what i wanted [09:37] <ubitux> enabled rpi && require_pkg_config rpi ... [09:38] <clever> yep [09:38] <ubitux> i guess [09:38] <clever> and add rpi somewhere [09:38] <clever> did similar things in mplayer config [09:38] <ubitux> you might hardcode the rpi path here actually if you insist on this [09:38] <ubitux> i'm not fond of having a special --enable-rpi flag though, but well [09:38] <ubitux> we can nitpick about it later [09:39] <clever> automatic would be best [09:39] <clever> if the files exist, just use them [09:40] <clever> enabled libv4l2 && require_pkg_config libv4l2 libv4l2.h v4l2_ioctl [09:40] <clever> package name, header file, function, i think? [09:41] <clever> ah, this area looks interesting [09:55] <clever> ubitux: got it working with --enable-rpi, auto isnt obvious yet [09:55] <clever> but thats good enough [10:24] <ubitux> sws: filterSize 256 is too large, try less extreem scaling or increase MAX_FILTER_SIZE and recompile [10:24] <ubitux> sws: initFilter failed [10:24] <ubitux> :(( [10:27] <nevcairiel> what did you try to scale [10:28] <ubitux> i tried to scale to too small (30x30) [10:28] <ubitux> (a 1080p source) [10:28] <ubitux> 32x32 seems ok [10:34] <ubitux> ’ ./ffmpeg -f lavfi -i testsrc=s=1920x1080 -vf scale=30:30 -f null - [11:40] <cone-200> ffmpeg.git 03Martin Storsjö 07master:09cd0a317620: doc: Add the host executable suffix for the print_options dependency [11:40] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:25010f511cb0: Merge remote-tracking branch 'qatar/master' [13:00] <BBB> ubitux: ok I'll push it somewhere, it's still not entirely finished but a bunch of fate tests pass at THREADS=2 now, not everything though [13:03] <clever> BBB: are there any docs somewhere on how to use check_pkg_config in configure?, it doesnt seem to auto detect the omx header files [13:04] <ubitux> there is no doc [13:04] <BBB> there is diego [13:04] <ubitux> clever: show your configure diff [13:04] <BBB> and between A and B, the answer is generally C [13:04] <clever> ubitux: one min [13:04] <BBB> that's just how it works [13:05] <BBB> but really no I don't know much about configure sorry [13:05] <clever> http://pastebin.com/ZraEs2eE [13:06] <ubitux> no no [13:06] <ubitux> not here clever [13:06] <ubitux> clever: look around line 4260 [13:06] <ubitux> and add an entry here [13:06] <ubitux> enabled rpi && require_pkg_config rpi ... [13:07] <clever> i did, thats in the paste at line 25 [13:07] <ubitux> ah my bad [13:07] <ubitux> what is the second check for then? [13:07] <ubitux> also, use the || die [13:07] <clever> the code nearby appears to force-enable things if certain headers are detected [13:08] <clever> so you dont have to --enable-rpi manualy [13:08] <ubitux> don't auto-detect this [13:08] <clever> why not? [13:08] <ubitux> if you have the headers locally to cross compile, you might not want all the time to have it cross compiled for rpi [13:08] <ubitux> think about packagers too [13:09] <clever> i guess [13:10] <clever> also, the cross compiler links against the wrong libc stuff, and produces useless binaries [13:10] <clever> so my only option is to build it directly on the pi, or in an array of pi vm's [13:32] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commits/vp9-frame-mt [13:34] <ubitux> wow that's a huge load of commits :) [13:55] <BBB> ubitux: well some refactoring was required [13:55] <BBB> also ignore the idct 32x32 obviously [13:55] <ubitux> :) [13:55] <BBB> maybe I should take that out... to prevent some new accident merges [13:59] <BBB> also feel free to debug while I'm off [14:00] <BBB> examples of fate tests that fail are vp9-00-quantizer-$high (e.g. 63, but sometimes down all the way to 33 or so) and all 01-sharpness-$N ones [14:00] <BBB> probably more [14:00] <BBB> I don't know why and havent' debugged much [14:01] <BBB> but visually the frames look pretty corrupt, suggesting some pretty weird stuff going on [14:24] <clever> BBB: http://pastebin.com/m5uvheQD which field should i populate with the frame data, and is it already allocated? [14:55] <clever> ->data i think [15:31] <cone-200> ffmpeg.git 03Vignesh Venkatasubramanian 07master:7f11c530dc3d: lavf: Exporting opus pre_skip in AVCodecContext [16:11] <plepere> ok, I'm losing my mind on this [16:11] <plepere> preparing a pastebin of this nonesense. [16:15] <plepere> http://pastebin.com/nA8Q9MFj [16:16] <ubitux> &ff_hevc_epel_filters + 1 [16:16] <plepere> how do I do to get the adress of ff_hevc_epel_filters[1] in assembly if +1 or +16 are both wrong ? [16:17] <nevcairiel> i think you shouldnt be using & [16:18] <clever> void foo[5];, foo is a pointer to element 0 [16:18] <ubitux> &ff_hevc_epel_filters+1 = 0xcc9d0  copy paste failing? [16:18] <plepere> okay [16:18] <clever> so you shouldnt be doing the bit that ubitux pasted [16:18] <ubitux> (it's missing a digit) [16:18] <plepere> yeh, copy pasting fail [16:18] <ubitux> clever: &ff_hevc_epel_filters is a pointer, +1 is +<ptr_size> [16:19] <clever> so ff_hevc_epel_filters isnt an array/pointer itself? [16:19] <nevcairiel> its two dimensional array, but the & is still wrong in this usage [16:19] <ubitux> mmh i derp at this actually [16:19] <plepere> ok, so if I remove the &, I get &ff_hevc_epel_filters[1]=ff_hevc_epel_filters+1 [16:20] <plepere> but shouldn't it be +16 ? [16:20] <ubitux> makes sense. [16:20] <nevcairiel> plepere: C knows the type of the array, so it knows how big one element is [16:20] <nevcairiel> its smart like that [16:20] <nevcairiel> asm doesnt have types [16:20] <plepere> so in assembly I should still do +16 then [16:20] <nevcairiel> it just has addresses [16:21] <plepere> the type is int8, so it's the same size [16:21] <nevcairiel> if the address if [1] is 16 higher then [0], then yes [16:21] <nevcairiel> which i hope it is from the structure :) [16:21] <nevcairiel> so yeah, use addressing like ff_hevc_epel_filters+x*16 [16:22] <ubitux> printf("%p\n", ff_hevc_epel_filters); [16:22] <ubitux> printf("%p\n", &ff_hevc_epel_filters[1]); [16:22] <ubitux> printf("%p\n", ff_hevc_epel_filters + 1); [16:22] <ubitux> ’ 0x400600 0x400610 0x400610 [16:22] <ubitux> +0x10 (16) [16:22] <plepere> ok [16:25] <plepere> so I should still do to access hevc_epel_filters[my] : shl myq,4 ;multiply by 16 [16:25] <plepere> movq m1,[hevc_epel_filters+myq] ;filter 0 [16:25] <nevcairiel> its easier to just add the *16 in the address [16:26] <nevcairiel> less instructions [16:26] <plepere> I get an invalid adress error [16:26] <plepere> invalid effective error [16:27] <nevcairiel> movq m1,[hevc_epel_filters+myq*10h] [16:27] <nevcairiel> that doesnt work? [16:27] <clever> its assembly, its not that smart [16:27] <clever> have to do the multiply and add in a seperate register [16:27] <plepere> nope [16:27] <nevcairiel> addresses support this [16:27] <clever> they do? [16:27] <nevcairiel> base+offset*multiplier [16:27] <ubitux> clever: it's a special form you can do that [16:27] <clever> ah [16:27] <plepere> maybe if I go by lea [16:28] <clever> i havent played with assembly beyond the 6502 and avr [16:28] <nevcairiel> not all registers can apparently be used for indexing [16:29] <plepere> even the lea instruction doesn't let me do myq*10h [16:29] <nevcairiel> are you sure my is a register? :p [16:29] <plepere> yes [16:30] <plepere> and I tested on the register directly too (r6) [16:31] <plepere> anyways, if you believe that the 2 lines I put are correct, I'll look for an error somewhere else then [16:32] <nevcairiel> maybe you need to load the address of hevc_epel_filters into a register first [16:32] <nevcairiel> possible that it cant do it with memory addresses [16:32] <nevcairiel> ie, lea tmp [hevc_epel_filters]; movq m1 [tmp+myq*16] [16:33] <nevcairiel> add commas where appropriate [16:33] <plepere> nope [16:33] <plepere> lea r10,[hevc_epel_filters] [16:33] <plepere> movq m1,[r10+myq*10h] [16:33] <plepere> doesn't compile [16:33] <nevcairiel> weird [16:33] <plepere> error: invalid effective address [16:35] Last message repeated 1 time(s). [16:35] <plepere> oops, sry [16:36] <plepere> i'll settle with this : [16:36] <plepere> shl myq,4 ;multiply by 16 [16:36] <plepere> lea r10,[hevc_epel_filters] [16:36] <plepere> lea r10,[r10 + myq] [16:36] <plepere> movq m1,[r10] [16:38] <nevcairiel> maybe we'll have a go at trying to clean such thigns once you have a working patch [16:38] <plepere> yes [16:39] <plepere> funnily enough, I do movq m8,[r10+2*srcstrideq] later in the code. [16:40] <nevcairiel> its probably just something stupid [16:40] <plepere> I did do movsxd myq,myd [16:40] <plepere> and sub myq,1 on the register beforehand [16:40] <ubitux> movq m1,[r10+16*myq] doesn't work? [16:41] <plepere> ubitux, no [16:41] <ubitux> doesn't assemble? [16:42] <plepere> compiler gives an "invalid effective address" error [16:43] <ubitux> mmh multiplier can't go above 8 indeed [16:44] <ubitux> 1,2,4,8 possible it seems [16:44] <nevcairiel> thats weird [16:44] <nevcairiel> shl myq, 4; movq m1, [hevc_epel_filters+myq] should in theory sitll work then? [16:44] <plepere> it does [16:45] <nevcairiel> at least shorter then all the leas [16:46] <plepere> but the image is incorrect [16:46] <plepere> but if you think that there are no pointer errors in there, I'll look in the rest. [16:47] <nevcairiel> did your leas give a correct image? [16:47] <plepere> no [16:47] <plepere> I think I have a problem with the hevc_epel_filters table access, but I might be wrong. [16:50] <ubitux> use gdb [16:51] <plepere> I'll have to follow a tutorial for that. :p [16:52] <plepere> I'll fiddle with my code and if I don't find anything elsewhere, I'll use gdb tomorrow [16:53] <ubitux> gdb --args ./ffmpeg_g -i in.hevc -f null - [16:53] <ubitux> b ff_hevc_... [16:53] <ubitux> r [16:54] <ubitux> and then "i r" (info registers) "i all-reg" (same with all regs) "ni" (next instruction) [16:54] <ubitux> "disas" [16:54] <plepere> do I need to set somewhere that I'm compiling ffmpeg for debug ? [16:54] <ubitux> ffmpeg_g has symbols [16:54] <ubitux> ffmpeg is stripped [16:54] <nevcairiel> --enable-debug in configure may help, but i dont think its required [16:54] <plepere> ok [16:54] <plepere> I'll test now since it seems that I have a guru willing to help me now [16:55] <nevcairiel> plepere: which functions are you working on right now? Maybe i'll try to convert one of the others you havent touched yet [16:56] <plepere> nevcairiel, I'm currently working on ff_hevc_put_hevc_epel_v_8_sse [16:56] <plepere> I already did qpel_pixels and epel_pixels [16:56] <plepere> grouped together as mc_pixels since they do the same thing [16:59] <plepere> I think qpel should be easy enough if you take a look at the intrinsics version of the code. [17:00] <ubitux> nevcairiel: i'm guessing it doesn't go above 8 because that's the max pointer size [17:00] <plepere> nevcairiel, if you can think of a smart way to use macros, it could be a great way to limit the functions that are quite numerous [17:01] <plepere> whoa, ubitux, I get plenty of nonesense with "i r". I'll take my time and try to grab what to look for [17:02] <plepere> it's quite easy to read actually [17:04] <plepere> but... [17:04] <plepere> cglobal put_hevc_epel_v_4_8, 9, 12, 0 , dst, dststride, src, srcstride,width,height,mx,my [17:05] <plepere> means that myq is on r6, right ? because "i r" shows it at r10 [17:05] <ubitux> i see 8 args, not 9 [17:05] <nevcairiel> all it means is that it will be in my [17:05] <nevcairiel> :) [17:05] <plepere> the last argument isn't used in this function [17:06] <nevcairiel> then reduce it to 8, no need to push it to a register [17:06] <plepere> it's a buffer used only in epel_hv. not in epel_h or epel_v [17:06] <plepere> ok [17:06] <ubitux> plepere: try a mov mx, mx and see which register it used in the assembly [17:07] <plepere> ok. [17:08] <plepere> I'm not using mx in this function, by the way. [17:08] <ubitux> well my if you prefer [17:08] <ubitux> :p [17:08] <ubitux> just giving you a way to figure out the registers [17:08] <plepere> I saw for my that the r10 register was changed when I did "sub my,1" [17:14] <plepere> well seems that the access is right. [17:14] <plepere> m1 has the right values [17:15] <plepere> dang [17:16] <plepere> found it ! [17:19] <plepere> well, found one error [17:19] <ubitux> arg it seems the AS test wasn't enough [17:19] <ubitux> llvm AS is behaving the same [17:34] <wm4> why does fflogger announce even insignificant changes like adding myself to CC... [17:34] <ubitux> so everyone can stalk you [17:34] <ubitux> all your nasty evil actions [17:35] <ubitux> i'm guessing it just watch "editedticket" event [19:21] <cone-200> ffmpeg.git 03Stefano Sabatini 07master:5e278c19c752: lavf/segment: add segment_list_entry_prefix option [19:21] <cone-200> ffmpeg.git 03Stefano Sabatini 07master:c0f2e0713566: lavf/segment: add a few log messages when avio_open2() fails [19:28] <saste> Daemon404, would you test my sdl event handler patch on windows? [19:29] <Daemon404> saste, can you wait till tomorrow morn? [19:29] <Daemon404> ust about to cook dinner for the SO [19:29] <saste> that or i'll have to spend a few hours setting up the compilation environment on windows [19:29] <saste> Daemon404, sure [19:29] <saste> "SO" ? [19:29] <nevcairiel> significant other [19:30] <Daemon404> what nevcairiel said [19:30] <nevcairiel> also, setting up a gcc env on windows isnt really all that hard, might just need to find the appropriate sdl library [19:30] <saste> ah ok, that's surely more important than testing some lame patch [19:31] <saste> nevcairiel, "really" ... "that hard", "just" ... "appropriate" -> dark magik [19:32] <nevcairiel> the main environment is just a big zip file you unpack and done [19:32] <saste> no really, i'm lazy [19:32] <wm4> the problem with sdl on windows is that it likes to do very stupid things [19:32] <wm4> like redirecting stdout to stdout.txt [19:32] <saste> wm4, s/on windows// [19:32] <saste> i just discovered a bug for which it is sending random videoresize events [19:32] <nevcairiel> the real problem with sdl is that it makes your build add -mwindows which builds a GUI application, and stdout is disabled by default [19:33] <nevcairiel> and of course our build system is so smart that it even does this for ffmpeg and ffprobe, instead of just ffplay [19:33] <saste> yes and they closed my ticket with no explanation, well really not even a work, just like that "closed" [19:33] <wm4> saste: it also likes to break on OSX mysteriously [19:33] <nevcairiel> so, i deleted sdl again [19:33] <saste> *not even a word* [19:33] <wm4> and libavcodec pulling in libsdl for no reason is a common problem [19:34] <saste> wm4, is that still happening? [19:34] <wm4> on my debian system: [19:34] <wm4> $ pkg-config --libs libavcodec --static [19:34] <wm4> -pthread -lavcodec -lXv -ldl -lva -lXfixes -lXext -lX11 -lcdio_paranoia -lcdio_cdda -lcdio -ljack -lasound -lSDL -ldc1394 -lnettle -lhogweed -lgmp -lssl -lcrypto -lzvbi -lxvidcore -lx264 -lvpx -lvorbisenc -lvorbis -lvo-amrwbenc -lvo-aacenc -lvidstab -ltheoraenc -ltheoradec -logg -lspeex -lschroedinger-1.0 -lrtmp -lpulse-simple -lpulse -lopus -lopenjpeg -lopencore-amrwb -lopencore-amrnb -lmp3lame -lgsm -lfdk-aac -lfaac -lbluray -lass -l [19:34] <wm4> aacplus -lraw1394 -lavc1394 -lrom1394 -liec61883 -lgnutls -lfontconfig -lfreetype -lcrystalhd -lbz2 -lz -lavutil -lm [19:34] <wm4> why is there -lSDL? [19:34] <nevcairiel> you sure link a lot of shit [19:34] <wm4> it was more than I expected [19:35] <wm4> looks like it includes crap from libavdevice [19:35] <wm4> even though libavcodec doesn't depend on libavdevice [19:35] <nevcairiel> is that what they call a full-featured version? :D [19:35] <wm4> probably [19:36] <nevcairiel> not caring about encoding much, luckily i barely get any requests for external libs [19:36] <nevcairiel> only got opus and speex i think [19:36] <wm4> sure, you have a self-contained environment [19:39] <ubitux> sdl is not the only insanity here btw [19:39] <ubitux> hello libass [19:39] <ubitux> -lXv [19:39] <ubitux> -lX11 [19:39] <ubitux> etc [19:39] <wm4> only if libass is linked against harfbuzz, and harfbuzz is linked against glib [19:39] <wm4> linking harfbuzz against glib is insanity [19:40] <ubitux> (wow @ libavfilter) [19:40] <wm4> there's a lightweight replacement for the functionality harfbuzz needed from glib (some unicode functions), so there's no excuse for linking it with glib [19:40] <wm4> if glib even links with X11 (huh) [19:40] <ubitux> the libs are actually appearing twice [19:40] <wm4> it's normal that libs appear twice [19:41] <wm4> they have to, if there are libs on libs dependencies [19:41] <ubitux> well [19:41] <ubitux> 4x for libavfilter [19:41] <ubitux> (try it) [19:41] <ubitux> wm4: did you open a ticket? [19:41] <wm4> for what? [19:41] <ubitux> for the sdl deps [19:42] <wm4> no, and I'm not sure if that issues was already raised or not [19:42] <saste> wm4, libavfilter -> movie -> libavdevice -> all insane stuff [19:42] <wm4> lol [19:42] <wm4> fun... [19:43] <ubitux> that doesn't explain the lavc case though [19:43] <saste> indeed [19:52] <cone-200> ffmpeg.git 03Marton Balint 07master:a02860351db5: ffprobe: add support for subtitle frames [20:06] <clever> /usr/bin/ld: error: ffmpeg_g uses VFP register arguments, libavutil/libavutil.a(log2_tab.o) does not [20:06] <clever> what usualy causes an error like this? [20:07] <Daemon404> this is on ARMv5 i take it? [20:07] <clever> 6 i think [20:07] <clever> Processor : ARMv6-compatible processor rev 7 (v6l) [20:07] <Daemon404> 6 has VFP i think [20:07] <Daemon404> i see [20:08] <clever> ah, i think its a leftover from the cross compile gone bad [20:08] <Daemon404> its been built with VFP when it shoulnt have then [20:08] <clever> the whole reason i was against using a cross compiler [20:08] <Daemon404> cross compilers are fine if you configure the toolchain and target properly. [20:09] <clever> the cross compiler has worked fine for producing kernels that run on this cpu [20:10] <Daemon404> yes but kernels probably dont have hand written VFP asm [20:10] <Daemon404> we do. [20:10] <clever> i dont think the kernel does ANY floating point [20:10] <clever> major performance issue [20:11] <clever> when entering things like an irq context, it saves the int registers, but ignores the float registers for performance [20:11] <clever> so its not safe to use any floating point in the kernel [20:12] <clever> i'll recompile the problem files and see how that works [20:13] <Daemon404> ... if you dont clean between builds, youre gonna have a bad time [20:14] <clever> it did clearly name the problem files, log2_tab.o [20:14] <durandal_1707> build problems again? [20:14] <clever> and it takes several hours to build, i'm not going to do another clean [20:21] <clever> /usr/bin/ld: error: ffmpeg_g uses VFP register arguments, libavcodec/libavcodec.a(hpeldsp_init_armv6.o) does not [20:21] <clever> Daemon404: hmmm, even some armv6 files had VFP missing [20:21] <clever> strange [20:21] <clever> but they have been rebuilt now [20:40] <nevcairiel> hey JEEB did you know that the mesa people jumped on the idiotic decode 10-bit-with-8-bit-decoder train? [20:41] <JEEB> yes [20:41] <JEEB> enough people have come to #mpv-player about it [20:42] <nevcairiel> I just lost all respect for the mesa project [20:42] <clever> ok, ive compiled ffmpeg with the hwaccel module [20:42] <JEEB> and my herps and derps ended up quoted on moronix's forums [20:42] <JEEB> and of course ignored [20:42] <durandal_1707> nevcairiel: why ? [20:42] <clever> is there anything special i have to give to ffplay to make it use that codec over the software one? [20:42] <JEEB> because "B-B-BUT IT PLAYS!" [20:42] <nevcairiel> because wrong decoding is worse then no decoding [20:43] <JEEB> sparked by someone adding the profile info into mesa IIRC? and now mesa itself thinks that it should be pushed into the decoder? [20:43] <JEEB> and not only retarded users? [20:43] <kierank> 7:40 PM <"nevcairiel> hey JEEB did you know that the mesa people jumped on the idiotic decode 10-bit-with-8-bit-decoder train? --? [20:43] <wm4> wait what [20:44] <wm4> did this end up as 10-bit decoded as 8-bit? [20:44] <nevcairiel> not sure if it was ever commited to gallium proper [20:44] <wm4> I thought this was about some mysterious chip that claimed to be 10 bit capable [20:44] <JEEB> no [20:44] <nevcairiel> but there was a patch flying around allowing decoding of 10-bit material with the 8-bit decoder soc [20:45] <clever> did i do that? lol [20:45] <JEEB> as far as I know, nothing has ever claimed being 10bit capable [20:45] <clever> i was trying to with the rpi!, lol [20:45] <JEEB> (in the end-user space) [20:45] <clever> but ffmpeg refused to do it at every turn [20:45] <wm4> I thought it was claimed to be 10 bit capable, even if the output was 8 bit [20:45] <JEEB> no [20:45] <nevcairiel> wm4: it uses 8-bit reference frames, even if the decoder can properly handle everything else, oyu lost there [20:45] <JEEB> all that was ever claimed was third party users saying that "hey, it decodes pictures! it's "buggy", but you can play it!" [20:46] <wm4> nevcairiel: heh, good point [20:46] <wm4> JEEB: I interpreted this as, "the code has still bugs, but in theory it should work fine" [20:46] <nevcairiel> they didnt really mention the "in practice it will always be wrong" part [20:47] <wm4> but this sure is a better explanation for the whole thing than a mysterious chip actually being 10 bit capable [20:47] <nevcairiel> any sane driver will simply reject it [20:47] <nevcairiel> gallium is hence insane now [20:48] <wm4> it's not the driver's business anyway [20:48] <wm4> unless they managed to add the hi10p profile to vdpau, and claim support for it [20:49] <nevcairiel> apparently they simply added it to the api [20:49] <JEEB> yes [20:49] <JEEB> so that instead of LOLDUNNO you get "yo dawg this is AVC" [20:49] <JEEB> and that got the retards rolling [20:49] <JEEB> at least user-wise [20:50] <JEEB> because the original patch used the word "decode" [20:50] <JEEB> for the act of parsing [20:50] <JEEB> not incorrect per se, but the reaction... [20:50] <JEEB> ugh [20:50] <wm4> to what "API" did they add what? [20:51] <JEEB> http://lists.freedesktop.org/archives/mesa-dev/2013-October/046943.html [20:51] <nevcairiel> apparently there is a libvdpau version that includes a hi10p profile in the enum now, and they added identifying the same to gallium [20:52] <JEEB> and http://lists.freedesktop.org/archives/mesa-dev/2013-October/047084.html [20:52] <clever> nevcairiel: i did try 10bit on vdpau just last week, it did nothing but spew errors and give no output [20:53] <clever> 10bit on the raspberrypi via omxplayer had some glitching in the graphics, probly an 8bit decoder [20:53] <JEEB> yes, because you have to pay lulzy sums for a 10bit H.264 compatible ASIC [20:54] <JEEB> as they're primarily aimed for professional use cases of intra H.264 [20:54] <wm4> still not seeing any patches or anything that would indicate they claim 10 bit support [20:54] <JEEB> yes [20:54] <wm4> oh wait [20:54] <wm4> I missed JEEB's second link [20:54] <nevcairiel> the first link already states that it can decode 10bit on uvd [20:54] <nevcairiel> "In opposite to our VDPAU implementation the H264 decoder supports Hi10P as well" [20:55] <wm4> hm http://lists.freedesktop.org/archives/mesa-dev/2013-October/047121.html [20:55] <nevcairiel> from some contributor that apparently works for amd [20:55] <wm4> the same guy says "As I don't know of any hw decoder that really does those things in 10 bits," [20:56] <JEEB> yup, it's mostly idiots misreading crap [20:56] <nevcairiel> still sounds like its trying to decode 10-bit [20:56] <JEEB> yes [20:57] <wm4> let's see if anyone says something about this in #dri-devel [20:57] <clever> JEEB: looks like i was wrong about the idea you gave me a few days ago [20:57] <clever> i thought the problem is because i was transforming the data into annexb, and sending the mkv header [20:57] <clever> but when i take the transform out, it still doesnt work [20:59] <clever> taking mplayer out of the loop and doing just raw ffmpeg [21:02] <durandal_1707> noooo [21:08] <wm4> <zgreg> wm4: as I said, the DPB is separate, it's on opaque buffer used by UVD [21:11] <smarter> The Internet: it's mostly idiots misreading crap [21:11] <clever> and a series of tubes filled with cats [21:12] <durandal_1707> The Universe: it's mostly nothing [21:12] <clever> :D [21:14] <llogan> The Nothing [21:15] <durandal_1707> The Perception [21:18] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:c3d5cd1ebfba: Revert "Merge remote-tracking branch 'qatar/master'" (43dec5ef9a360c9ffac3278f464832bd99af0cb0) [21:52] <llogan> michaelni: /home is completely full preventing any commits to ffmpeg-web [22:23] <Compn> who was working on subtitles ? [22:23] <Compn> heres subtitles in flv i've never seen before > http://ht.cdn.turner.com/adultswim/big/AS_HD_nongeo/rickandmorty/2013/11/ric... [22:24] <Compn> Stream #0:2(eng): Subtitle: mov_text (tx3g / 0x67337874), 640x360, 3 kb/s (default) [22:24] <Compn> oh nevermind , it is .mov ? [22:26] <wm4> yes it is [22:27] <Compn> wm4 : do the subs work in your mpv ? [22:27] <Compn> i have an old version, it looks bad here [22:27] <Compn> old mplayer that is [22:27] <llogan> that's because you're using Windows 2000 [22:27] <Compn> llogan : no! i killed that box to add in a 4tb drive [22:27] <wm4> Compn: no they don't [22:27] Action: llogan is flabbergasted [22:28] <Compn> i know :( [22:28] <Compn> win2k lasted me 13 years :( [22:28] <wm4> I get some strange shit [22:28] <llogan> i just retired a pentium II machine this week [22:28] <Compn> llogan : i upgraded to the latest in operating systems, circa 2002, winxp! [22:28] <Compn> i would have done a full linux install, but ubuntu recently has shown its true colors and is not trustworthy anymore [22:29] <llogan> i hear there are other distros [22:29] <Compn> so i need to settle on a new distribution [22:29] <Compn> which requires testing first... [22:29] <llogan> and xp is trustworthy? [22:29] <Compn> xp was already installed [22:29] <Compn> but no, no its not [22:31] <wm4> Compn: why don't you switch to a REAL os? [22:31] <Compn> wm4 : they work in the flash player [22:31] <Compn> the subs [22:32] <wm4> Compn: I can check it out later [22:32] <Compn> wm4 : suggestions for linux or bsd distros are welcome [22:32] <wm4> does it work in ffplay? [22:32] <Compn> how do i enable subs in ffplay [22:32] <wm4> I have no idea how to make subs work in ffplay in general [22:32] <wm4> meh [22:32] <llogan> paul is the only person here who uses BSD, AKAIK [22:34] <Compn> wm4 : no, it looks like ffplay does not display any subs [22:34] <Compn> for this file [22:35] <wm4> well, the subs might just use some extended features [22:35] <Compn> i'm not sure mov_text is highly supported in anything except quicktime nonsense [22:35] <Compn> the subs look like closed captioning in the flash player [22:36] <Compn> great, now that url i posted, i dont think i can find it. keeps redirecting me to another page [22:37] <Compn> i mean so i can see what it looks like in the flash player anymore haha [22:37] <Compn> now there is .webm file [22:37] Action: Compn downloads [22:41] <Compn> wm4 : maybe i'll checkout SteamOS ? :P [22:41] <Compn> ehehe [23:28] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:4782c4284fa3: avcodec/ac3dec: check bap before use. [00:00] --- Tue Nov 26 2013