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

[burek]

[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 at 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/rickandmorty_cc_001_pt1_t3LEd_AS_HD_large.flv
[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