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

[burek]

[00:00:11 CET] <j-b> michaelni: well, I'm fighting with my Rémi over this issue, atm
[00:00:27 CET] <j-b> pfff, pain in the neck, some people are, over semantics
[00:01:09 CET] <wm4> check the processname, if it's vlc, don't print the message
[00:01:27 CET] Action: wm4 runs
[00:01:42 CET] <michaelni> j-b, ok, thanks, ill wait
[00:02:08 CET] <j-b> wm4: lol
[00:02:34 CET] <JEEB> were there any other "wallclock as timestamp" kind of things than that one parameter added in 2012 or so?
[00:03:00 CET] <JEEB> basically I was thinking of something like itsoffset except having it get current time
[00:03:13 CET] <JEEB> and have that as the initial offset for timestamps
[00:04:16 CET] <JEEB> as some livestreaming thingies seem to like such
[00:21:37 CET] <cone-628> ffmpeg 03Carl Eugen Hoyos 07master:44cf5b41d33a: lavfi/nnedi: Fix a memleak.
[00:24:05 CET] <cone-628> ffmpeg 03Carl Eugen Hoyos 07master:37afeabd1b83: lavfi/nnedi: Fix a compilation warning.
[01:22:44 CET] <cone-628> ffmpeg 03James Almer 07master:45d3af90593a: x86/dcadec: add ff_lfe_fir1_float_{sse3,avx}
[01:40:20 CET] <JEEB> I guess I'll throw this for review tomorrow https://github.com/jeeb/ffmpeg/commits/isml_improvements
[01:51:33 CET] <ethe> JEEB: how do I test an output avdevice?
[02:00:34 CET] <ethe> got it: ffmpeg -i movie.mkv -f sdl2 "title" -f sdl2 "SDL2 test title"
[02:17:01 CET] <ethe> so, I mostly got SDL2 avdevice output working, but it seems to be playing at 3x speed
[02:17:47 CET] <ethe> looks like it's not getting rate limited or something like that
[02:26:05 CET] <Timothy_Gu> ethe: try ffmpeg -re -i movie.mkv -f sdl2 bleh
[02:26:53 CET] <ethe> that works a lot better
[02:27:08 CET] <ethe> well, it's at the right fps now
[02:29:11 CET] <ethe> Timothy_Gu what exactly is the sdl output meant to do?
[02:36:14 CET] <Timothy_Gu> ethe: well& it's supposed to display video using libSDL?
[02:37:19 CET] <Timothy_Gu> From man page: -re Read input at native frame rate. By default ffmpeg attempts to read the input(s) as fast as possible.  This option will slow down the reading of the input(s) to the native frame rate of the input(s).
[02:37:53 CET] <ethe> ah, so -f sdl is like a raw output kinda thing
[02:47:38 CET] <ethe> Timothy_Gu do you know if the window should be able to be dynamically resized?
[02:48:07 CET] <Timothy_Gu> ethe: you should focus on getting feature parity at this point
[02:48:13 CET] <Timothy_Gu> did sdl support dynamic resizing?
[02:48:29 CET] <Timothy_Gu> I didn't check but I don't think so, so I'd say no
[02:48:56 CET] <ethe> maybe? "case SDL_VIDEORESIZE"
[02:49:27 CET] <ethe> I'm not sure, I only have 1080p video, but my screen resolution is lower, so I can't get to the bottom right corner of the video to test resizing
[02:49:43 CET] <ethe> which is a bad excuse, I should just get some lower res video
[02:51:34 CET] <Timothy_Gu> ethe: you can use -f lavfi -i testsrc
[02:51:58 CET] <Timothy_Gu> i.e. using the testsrc video source filter
[02:52:22 CET] <ethe> yeah, anyway to output yuv420p, yuyv422, or uyvy422 with that?
[02:52:42 CET] <ethe> input*
[02:55:34 CET] <ethe> got it. -pix_fmt yuyv422
[03:18:48 CET] <ethe> Oddly enough there seems to be two output 'files' which seems to be messing up the threads
[03:19:54 CET] <ethe> .-. that might be because I set two outputs...
[03:44:58 CET] <Timothy_Gu> ethe: how?
[03:45:06 CET] <Timothy_Gu> don't tell me SDL is not thread-safe...
[05:24:26 CET] <cone-628> ffmpeg 03James Zern 07master:7586b3adf229: libvpxenc: quiet unused-variable warning
[08:56:25 CET] <JEEB> wbs: when you have the time could you check these two patches (since you IIRC originally made these) https://github.com/jeeb/ffmpeg/commits/isml_improvements
[08:56:42 CET] <JEEB> (these muxers)
[09:03:59 CET] <ethe> Timothy_Gu it doesn't look like the original SDL device is (not that I've tested it)
[11:55:54 CET] <ubitux> http://b.pkh.me/psysrc.webm mixing up chroma can be artistic
[12:10:26 CET] <JEEB> yeah, I remember the times when hw decoders and renderers mismatched each other
[12:10:32 CET] <JEEB> led to some pretty fabulous results
[12:10:46 CET] <JEEB> (add corrupted decoding results to the mix, too)
[12:12:31 CET] <ubitux> here the glitch was because the chroma linesizes were used 4x instead of 2 (yuv420p); i like the wave effect it has on testsrc2 pattern
[12:13:41 CET] <ubitux> i wonder if i can reproduce this with a filter
[12:13:52 CET] <ubitux> anyway.
[12:14:06 CET] <JEEB> oh right, the wave update effect
[12:15:16 CET] <ubitux> there is also a libvpx fuckery in the process
[12:15:34 CET] <ubitux> which is actually probably responsible for this wave effect
[12:27:49 CET] <jkqxz> ^ what?  Application-Specific Integrated Circuits are application-specific, maybe.
[12:41:14 CET] <nevcairiel> people just read that ASICs are super fast for one task and think, hey why cant it be fast for another task!
[12:43:35 CET] <ubitux> when are we going to stop allowing markup on the trac :(
[12:43:46 CET] <ubitux> users are so dumb :(
[12:44:21 CET] <ubitux> we need to make stats, but i feel like it's something around 4/5 users fail at markup
[13:53:48 CET] <JEEB> wbs: thanks for the comments :)
[13:54:16 CET] <JEEB> I might have been a bit tired
[13:55:43 CET] <JEEB> funny how I didn't see edts in the boxdumper (when doing ISM at least). I was trying to see where else timestamps could be written
[13:56:17 CET] <JEEB> but yes, if we are making a generic option it should also work with those
[15:03:50 CET] <Timothy_Gu> https://trac.ffmpeg.org/ticket/5259#comment:10 ugh
[15:13:16 CET] <nevcairiel> Timothy_Gu: also http://pastebin.com/NN2A0nGG configure with --cpu=haswell on x86_32
[15:14:02 CET] <nevcairiel> inline asm and autovec dont like each ohter
[15:37:08 CET] <ubitux> http://pastie.org/pastes/10734275/text i fucking hate gdb somet^Wall the time
[15:48:38 CET] <Timothy_Gu> nevcairiel: would a patch adding a function attribute asking gcc to skip vectorizing such a function be acceptable?
[15:48:59 CET] <Timothy_Gu> av_novectorize
[15:52:26 CET] <cone-175> ffmpeg 03Carl Eugen Hoyos 07master:2aa21eec1adc: postproc: fix unaligned access
[15:58:59 CET] <cone-175> ffmpeg 03Carl Eugen Hoyos 07release/3.0:449ff0e3fd47: postproc: fix unaligned access
[15:59:00 CET] <cone-175> ffmpeg 03Oliver Collyer 07release/3.0:b80083a5c17a: ffserver&ffm: Fixed issues preventing ffserver write_index and files_size from being set correctly which was breaking ffserver streaming.
[16:04:19 CET] <wm4> this shit is so inconsistent... try_decode_frame() in libavformat/utils.c also tries partial video packet decoding
[16:04:46 CET] <wm4> even though it explicitly prevents it for subtitles
[16:19:05 CET] <cone-175> ffmpeg 03Muhammad Faiz 07master:6eb4021d47cc: avfilter/avf_showcqt: use lrint
[16:19:08 CET] <BBB> why do we have autovec anyway
[16:19:21 CET] <BBB> in cases where autovec helps, isnt that an indication we should hand-write some simd?
[16:19:28 CET] <BBB> its not like we have a shortage of x86 simd authors
[16:21:17 CET] <J_Darnley> Some on us are pretty mediocre though.
[16:21:27 CET] <J_Darnley> *of
[16:22:07 CET] <J_Darnley> Well, I know at least one of us is.
[16:31:09 CET] <durandal_1707> you?
[16:31:55 CET] <J_Darnley> yes
[16:32:11 CET] <durandal_1707> it helps for vf_phase dunno how much compared to hand written one
[16:32:55 CET] <durandal_1707> BBB: write utvideo SIMD?
[16:32:58 CET] <wm4> I say our asm should be robust enough that this should not happen? modulo compiler bugs
[16:38:38 CET] <nevcairiel> well inline asm walks all over compiler smarts and really restricts what it can do, so its not unheard of that it causes all sorts of problems
[16:39:20 CET] <nevcairiel> yasm is of course unaffected
[17:17:20 CET] <wm4> evil plan 2 was pushed in Libav
[17:17:37 CET] <nevcairiel> see me care this much: || :P
[17:17:50 CET] <durandal_1707> so merge it
[17:18:03 CET] <nevcairiel> like i said over there, its extremely underwhelming, its only for his need of cleanliness, as an api user it doesnt benefit me
[17:24:49 CET] <iive> is that renaming of codec into codecpar in 300 files?
[17:25:09 CET] <iive> and having separate patch for every file?
[17:25:25 CET] <nevcairiel> that was only for review purposes
[17:26:51 CET] <iive> yeh, 300 mails really make things easier to review :Z
[17:30:53 CET] <ubitux> so we're going to need to rush a merge?
[17:31:12 CET] <nevcairiel> why
[17:31:15 CET] <ubitux> or can it be done progressively?
[17:31:21 CET] <nevcairiel> no
[17:31:24 CET] <nevcairiel> well kinda
[17:31:32 CET] <nevcairiel> you can fix it in some other git repo and push it once its done =p
[17:31:41 CET] <ubitux> yeah right, so just like last time
[18:00:31 CET] <cone-175> ffmpeg 03Mats Peterson 07master:3ba57bfe8ddc: lavf/riffenc: Handle AV_PIX_FMT_MONOBLACK
[18:32:35 CET] <ethe> hmm, does sdl outdev currently work on OSX? (it doesn't work for me)
[18:33:29 CET] <nevcairiel> i doubt many people use these outdevs, they are rather obscure
[18:38:48 CET] <JEEB> such audio/video rendering avdevices are quite weird
[18:52:57 CET] <ethe> indeed, I cannot see a point for them other than maybe a live preview
[18:56:14 CET] <ethe> JEEB: I just wanted a baseline for SDL2, because I'm not quite sure how SDL looked/performed. So I tried to revert back to SDL to check, and it doesn't even work :( I'm just trying to find out: did it have window borders, was it resizable?
[18:56:56 CET] <cone-175> ffmpeg 03Stefano Sabatini 07master:14f7a3d55a43: lavc/lavf: transmit stream_id information for mpegts KLV data packets
[19:08:33 CET] <Timothy_Gu> ethe: for window borders etc. it's usually platform-dependent
[19:09:19 CET] <ethe> Timothy_Gu: SDL2 standardises it iirc, you either set them on or off.
[19:09:33 CET] <Timothy_Gu> then add an option
[19:09:45 CET] <Timothy_Gu> i'd default to true
[19:12:49 CET] <Timothy_Gu> also what do you mean it doesn't work?
[19:13:45 CET] <ethe> it doesnt display the window, and throws no errors (event with -v trace)
[19:18:09 CET] <Timothy_Gu> works fine on windows (I'm at school so I' don't have access to linux but it probably works too)
[19:19:11 CET] <Timothy_Gu> it does have window borders, and though it's "resizeable," it's broken, (pixels outside of the image are not zeroed)
[19:19:16 CET] <ubitux> ok, finally able to reproduce yuv420p-to-rgba mmx code in C using the generic yuv2rgb constants 
[19:19:23 CET] <ubitux> here it is for the record http://pastie.org/10734602 before i lost it
[19:19:46 CET] <ubitux> now i can make the arm/aarch64 consistent with this 
[19:19:54 CET] <ubitux> by fixing the current 16-bit path and dropping the 32
[20:01:49 CET] <jamrial> ubitux: you mean there was no c version already? only mmx?
[20:02:07 CET] <ubitux> bitexact with mmx there isn't any
[21:04:29 CET] <ubitux> "pcmpeqd   %%mm"REG_ALPHA", %%mm"REG_ALPHA"\n\t" /* set alpha to 0xFF */
[21:04:40 CET] <ubitux> heh, funny way of doing that
[21:04:46 CET] <JEEB> wait what
[21:05:32 CET] <ubitux> pcmpeqd m0,m0
[21:05:34 CET] <JEEB> oh right, "If a pair of data elements is equal, the corresponding data element in the destination operand is set to all 1s"
[21:12:36 CET] <nevcairiel> its pretty common way of 1'ing a reg
[21:13:22 CET] <J_Darnley> I must keep that trick in mind.
[21:20:21 CET] <Mavrik> Hmm, I have stream checkers going a bit crazy around PCR jitter for ffmpeg generated MPEG-TS streams. Is that considered ticket worthy?
[21:22:18 CET] <JEEB> it is, unless there's already a ticket for that. generally the libavformat muxer has so far been barely usable for the dumber scenarios (HLS et al)
[21:23:35 CET] <Mavrik> Yeah :/
[21:23:42 CET] <Mavrik> I guess we have no OSS alternatives?
[21:26:44 CET] <JEEB> see VLC's muxer I guess? or kierank's?
[21:27:01 CET] <JEEB> there are multiple libraries (libdvbpsi, whatever that other thing was?)
[21:27:06 CET] <JEEB> biTStream?
[21:29:28 CET] <ubitux> is it OK in x86 to alter the stack area where the arguments of the function are?
[21:30:00 CET] <Mavrik> JEEB, ah, I'll take a poke and make a ticket for ffmpeg as well :)
[21:30:04 CET] <Mavrik> thanks
[21:30:13 CET] <J_Darnley> ubitux: sometimes
[21:30:23 CET] <ubitux> "sometimes"? :(
[21:30:38 CET] <J_Darnley> see the problem with my recent h264 patch
[21:31:08 CET] <J_Darnley> If you don't ask for stack space then it is fine
[21:31:08 CET] <nevcairiel> stack handling is tricky when considering all available platforms
[21:31:27 CET] <nevcairiel> its also fine if oyu have enough regs for a stack pointer
[21:31:38 CET] <nevcairiel> but that leaves only 6 to work with on x86
[21:33:03 CET] <ubitux> sadness
[21:33:18 CET] <ubitux> i'm going to have a bad time with these 13 args
[21:33:28 CET] <nevcairiel> probably
[21:33:36 CET] <nevcairiel> should re-think the signature if you really need them all =p
[21:33:43 CET] <J_Darnley> if you do need stack space then adjust manually and remember it can be unaligned.
[21:33:49 CET] <ubitux> nevcairiel: yeah i really do unfortunately
[21:34:07 CET] <ubitux> OR, i could add a struct to contain them all
[21:34:17 CET] <nevcairiel> that doesnt really change anything
[21:34:25 CET] <nevcairiel> now the "struct" is the stack
[21:34:37 CET] <ubitux> there are helper to access the struct field
[21:34:56 CET] <ubitux> i can have like 3 args, including a pointer to the struct params, and directly access fields
[21:35:01 CET] <ubitux> and still have a bunch of reg to play with
[21:35:05 CET] <ubitux> maybe i should do that
[21:35:13 CET] <nevcairiel> i dont see how that changes anything
[21:35:31 CET] <nevcairiel> right now you can just access all fields from the stack when you need them
[21:35:57 CET] <nevcairiel> afterwards you need an extra layer of indireciton to load the address and then load the entry
[21:36:11 CET] <nevcairiel> or keep the address in a reg permanently, but same deal
[21:36:18 CET] <ubitux> but many reg are used to contain parameters by default, right?
[21:36:39 CET] <ubitux> so even though i can access directly extra args on the stack, i have my reg "saturated"
[21:37:50 CET] <ubitux> anyway, i'm goign to try without a struct first
[21:38:58 CET] <nevcairiel> x86 cdecl ABI passes all arguments on the stack iirc
[21:39:24 CET] <kurosu_> yes
[21:39:42 CET] <nevcairiel> x64 is a bit weirder, it passes a few in regs, and also depending on win64 or unix64
[21:39:48 CET] <kurosu_> WIN64 and ??? (SYSV64?) behave differently
[21:40:51 CET] <wm4> amazing, something as simple as vf_copy is broken
[21:41:10 CET] <wm4> it accepts hwaccel formats, without treating them correctly
[21:41:27 CET] <nevcairiel> sounds like its "too simple" =p
[21:41:28 CET] <ubitux> hwaccel were recently allowed in lavfi
[21:41:33 CET] <ubitux> they weren't previously
[21:41:41 CET] <ubitux> poke anton
[21:41:43 CET] <wm4> whatever that means
[21:41:50 CET] <ubitux> hwaccel pixfmts*
[21:41:53 CET] <nevcairiel> lavfi blocked them entirely before
[21:42:09 CET] <ubitux> see ae25413d
[21:42:21 CET] <wm4> ah, makes sense
[21:43:11 CET] <wm4> is there a vf_nop?
[21:43:23 CET] <nevcairiel> whats it do, eat your frames?
[21:43:30 CET] <ubitux> passthrough?
[21:43:37 CET] <wm4> like vf_copy, except not copying
[21:43:40 CET] <ubitux> try select=1
[21:43:44 CET] <nevcairiel> why would that exist :D
[21:43:52 CET] <nevcairiel> but yeah select can probably fake that =p
[21:44:00 CET] <wm4> ubitux: that works
[21:44:14 CET] <ubitux> maybe a bit slow
[21:44:28 CET] <ubitux> lemme check if we have another one&
[21:44:35 CET] <wm4> nevcairiel: well, sometimes you might want to be able to have the user to specify a "connection" between a src and a sink, without any actual filters
[21:44:53 CET] <wm4> since the graph parser can't connect them directly, you need a dummy filter (apparently)
[21:45:57 CET] <ubitux> ah, null!
[21:46:07 CET] <ubitux> vf_null should do that
[21:46:38 CET] <wm4> ah, indeed
[21:47:15 CET] <wm4> I would think of null something that eats all input, though
[21:48:06 CET] <Timothy_Gu> wm4: that's nullsink
[21:49:20 CET] <wm4> makes sense
[22:45:26 CET] <kierank> what happened to __gb__
[22:52:30 CET] <wm4> good question
[23:10:24 CET] <ethe> where are AV_PIX_FMT_*s defined?
[23:10:36 CET] <nevcairiel> avutil/pix_fmt.h or something
[23:10:38 CET] <nevcairiel> maybe pixfmt.h
[23:10:41 CET] <nevcairiel> one of thsoe
[23:10:47 CET] <wm4> really just takes a grep...
[23:11:06 CET] <nevcairiel> or my favorite, an IDE =P
[23:12:44 CET] <ethe> ah I was looking in pixdesc.h for some reason, thanks.
[23:13:30 CET] <wm4> but IDEs are evil and immoral
[23:13:48 CET] <wm4> grep and sed are the best refactoring tools
[23:14:10 CET] <wm4> and gdb... well let's not go this way
[00:00:00 CET] --- Wed Feb 24 2016