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

[burek]

[00:03] <JEEBsv> uhh, I don't think the handler is meant for that kind of data :s
[00:04] <JEEBsv> although I don't remember the definition in the spec
[00:04] <nevcairiel> many things abuse it for track titles
[00:04] <nevcairiel> but technically its supposed to have a technical meaning
[00:04] <JEEBsv> yes
[00:04] <nevcairiel> not sure what the actual track title atom was in mov/mp4
[00:07] <Zeranoe_> nevcairiel: that does seem to work, for the audio handler_name. I'll have to experiment to get it to work for subtitles
[00:07] <JEEBsv> l-smash seems to have itunes title metadata
[00:07] <nevcairiel> it should work the same way, use -metadata:s:s for the subtitle stream, or use integer indexes for individual stream numbers
[00:08] <JEEBsv> not track-specific it seems
[00:08] <JEEBsv> although I'm not sure of the details
[00:09] <nevcairiel> well if the format itself would truely lack such a feature, no wonder people abuse the handler for that
[00:09] <JEEBsv> yeah, track options in L-SMASH are: fps/language/handler
[00:09] <muken> mp4 has no track title atom. mov and 3gpp have though
[00:11] <Zeranoe_> nevcairiel: Bingo, s:s did it. Thank you
[00:24] <Tim_G> ubitux: mail client problem
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.11-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n0.11-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.12-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n0.12-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.1-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n1.1-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.2-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n1.2-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.3-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n1.3-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.1-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n2.1-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.2-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n2.2-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.3-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n2.3-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.4-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n2.4-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.5-dev': unknown revision or path not in the working tree.
[01:08] <cone-963> Use '--' to separate paths from revisions
[01:08] <cone-963> refs/tags/n2.5-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:25] <ubitux> lol
[01:33] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.6-dev': unknown revision or path not in the working tree.
[01:33] <cone-963> Use '--' to separate paths from revisions
[01:33] <cone-963> refs/tags/n2.6-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf'
[01:37] <jamrial> michaelni: you typoed the description of the n2.6-dev tag :p
[01:42] <michaelni> j-b, can you force push a n2.6-dev tag with "2.4" replaced "2.5" ?
[01:42] <michaelni> in the commit message
[01:43] <michaelni> that is what the following would generate git tag -m 'Main development, master branch after release/2.5 branched off'  -a -f n2.6-dev f478bdabf2afcd5f709789347f8a3becc4ff17bc
[01:44] <michaelni> i cant fix it myself as "git push origin  n2.6-dev  -f" gives ! [remote rejected] n2.6-dev -> n2.6-dev (hook declined)
[01:58] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:c263102298ec: avcodec/vdpau: fix assertion failure and < vs > error
[02:55] <cone-963> ffmpeg.git 03Simon Thelen 07master:cc63da1223da: ffmpeg: add sdp_file option
[03:04] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:627f5658b68f: ffmpeg: Use av_freep(), avoid leaving stale pointers in memory
[12:51] <anshul__> is there already some function to convert int to string or should I use sprintf
[12:54] <anshul__> i got its av_d2str
[14:20] <ubitux> a8eb52a8c32536a1b93bebe2d0372edf1a520501  anyone knows why?
[14:53] <BBB> ubitux: because pthread is the standard api used for threading code?
[14:54] <ubitux> i don't know; aren't semaphore also posix standardized?
[14:59] <aetasx> yeah
[15:02] <aetasx> I was waiting for testdisk to finish running last night which takes forever and came across a National Geographic special with possibly the worst name ever
[15:08] <ubitux> ==31803== ERROR SUMMARY: 4302161 errors from 45 contexts (suppressed: 394 from 96)
[15:09] <wm4> ubitux: uh well it uses mutexes and condvars instead of semaphores?
[15:09] <ubitux> i really wonder by what miracle we don't see any problems
[15:09] <ubitux> wm4: yes; the question is why is it more appropriate
[15:09] <wm4> ubitux: or something else?
[15:09] <wm4> well semaphores can be slower, I guess
[15:09] <wm4> and OSX doesn't implement them
[15:09] <ubitux> (it's a naive question from someone who has not much clue)
[15:09] <ubitux> ok
[15:09] <wm4> (despite OSX being POSIX certified, hurr)
[15:10] <wm4> it also might be that the code is simpler after that change, but I didn't check if that's the case
[15:11] <ubitux> you sure it's not available on osx?
[15:12] <rcombs> it's a bit shorter after the change; dunno about simpler per se
[15:12] <rcombs> (not reading all that right now)
[15:13] <wm4> ubitux: very sure
[15:13] <wm4> OSX has named semaphores, but not normal ones
[15:13] <ubitux> ok
[15:31] <akira4> ubitux, would you please have a look at this diff if you're free? http://pastebin.com/5BA4MKm5. 
[15:31] <ubitux> gonna look at this, give me an hour
[15:31] <akira4> sure. thanks
[15:32] <aetasx> ubitux: did you ever decide whether you're going to merge read and nav together?
[15:33] <ubitux> that's not up to me
[15:33] <ubitux> i'm not a libdvd* dev at all
[15:34] <aetasx> fork it then ;)
[15:35] <ubitux> i already have my quota of insane things to deal with
[15:36] <aetasx> whats your primary role around here anyway?
[15:38] <aetasx> like what all areas do you work on
[15:40] <ubitux> goldbricking maybe
[15:41] <iive> libdvd is so forked it is quite troublesome to find what version is currently in development.
[15:41] <wm4> iive: simple, the videolan one
[15:41] <aetasx> how dare you make me look up a slang term
[15:42] <ubitux> more seriously, my current projects wave between (mainly text) subtitles, mov edit list, nlmeans filter, mentoring the dvd stuff
[15:42] <ubitux> i'm having troubles getting some shit done thought
[15:42] <iive> also, DonDiego seems to have abandoned libav and moved to libdvd in vlc, so expect a lot of puzzling cleanups.
[15:42] <aetasx> to be fair, holidays aren't really the time when things get done anyway
[15:43] <ubitux> well, that's actually the best opportunity to get things done
[15:43] <iive> depends... on whenever you code in your work or free time.
[15:43] <aetasx> or you have any interest in being around your family
[15:44] <ubitux> (ah, and i started looking again at why helgrind is complaining so much, but i hate threading so much to look at this peacefully)
[15:45] <ubitux> no fuck given for my family; this is my free time, i'm definitely not going to share a single second for them :p
[15:45] <wm4> why hate threading
[15:45] <aetasx> I wouldn't want to deal with it specifically in as far as encoding goes at least.  Trying to figure out how best to dish out frames seems like a nightmare
[15:46] <ubitux> wm4: mainly because of my ineptitude & confusion :)
[15:46] <ubitux> wm4: i just don't like the idea of being unable to know if i'm doing anything wrong with the current state of ffmpeg regarding threading
[15:46] <ubitux> and that's kind of frustrating
[15:47] <ubitux> i mean, try something as simple as valgrind --tool=helgrind ./ffmpeg_g -nostats -i ~/fate-samples/utvideo/utvideo_rgb_median.avi -f null -
[15:47] <ubitux> and see the shitstorm
[15:47] <ubitux> most of it is related to the state variable in pthread_frame.c, so i'm assuming we're kind of doing something somehow undefined around here
[15:48] <ubitux> there are many other issues, but they're (partly) hidden because of this one
[15:49] <aetasx> thats one of the reasons why I usually am hesitant to get too deeply involved in things in general
[15:49] <aetasx> get worried about if something is the way it is for a specific reason
[15:49] <ubitux> it's in the way because it prevents from using these tools when adding threading elsewhere
[15:50] <ubitux> and it's also annoying because it's wasting resources (kind of entirely my fault here thought); we have instances with drd, helgrind and tsan
[15:50] <ubitux> but they are vomitting so much errors, the relevant ones are lost in it
[15:51] <ubitux> and all of them take a lot of time to process
[15:51] <ubitux> (a fate run of helgrind takes several hours typically)
[15:51] <aetasx> jesus
[15:52] <ubitux> we were forced to drop the details from the main fate page too
[15:52] <ubitux> because a report is several GB in size
[15:53] <aetasx> are all those lines unique though?  can't you just prune dups out of it?
[15:53] <ubitux> -rw-r--r-- 1 ux ux 3.3G Dec 28 10:16 fate/x86_64-archlinux-gcc-valgrind-threads/report
[15:53] <ubitux> -rw-r--r-- 1 ux ux 2.3G Dec 28 15:14 fate/x86_64-archlinux-gcc-valgrind-drd/report
[15:53] <wm4> ah I see a "volatile" in the code
[15:54] <wm4> it's probably evil code
[15:54] <ubitux> aetasx: or we could fix the code...
[15:54] <aetasx> sounds like libav sabotage to me
[15:54] <aetasx> :p
[15:54] <wm4> ubitux: do you have some example error report?
[15:55] <wm4> just so I can take a look and give up
[15:55] <aetasx> I bet it'll at least compress pretty well
[15:55] <ubitux> wm4: http://fate.ffmpeg.org/report.cgi?time=20141228091535&slot=x86_64-archlinux-gcc-valgrind-threads i guess
[15:55] <ubitux> try "stderr" on any of the test
[15:57] <wm4> why are there failed audio tests?
[15:57] <ubitux> probably because of the threaded demuxing or something
[15:57] <ubitux> (you know, for multiple inputs)
[15:58] <wm4> interesting
[15:58] <ubitux> actually
[15:58] <wm4> the page is very slow
[15:58] <ubitux> that might just be because of threaded frame decoding
[15:58] <ubitux> so it still the same thing
[15:58] <wm4> and crashed firefox (what=
[15:58] <ubitux> wm4: report is 3G+
[15:58] <aetasx> you miss the part where it was 3gb?
[15:59] <ubitux> note: a normal report is around 10M
[15:59] <ubitux> tsan is the smallest of the 3: 429M
[16:00] <wm4> also this page uses javascript shit
[16:00] <wm4> so you can't actually click on "stderr"
[16:00] <wm4> because it needs JS
[16:00] <wm4> which also means you can't just wget it or so
[16:01] <wm4> maybe you have to wait until the page has loaded
[16:01] <wm4> ...
[16:01] <aetasx> I'd pull it up and look at a way of doing it but Ill pass on the 3gigs
[16:01] <ubitux> lavf-mov test is fun
[16:01] <aetasx> doubt any browser could survive that
[16:01] <ubitux> ==11772== ERROR SUMMARY: 1269306 errors from 890 contexts (suppressed: 1098 from 89)
[16:02] <ubitux> you can also just run the command i gave earlier if you want a random output
[16:02] <ubitux> i mean, almost any fate test is triggering the problem
[16:05] <aetasx> was it always like this?
[16:06] <ubitux> yes
[16:06] <ubitux> i think nicolas fixed the threaded demuxed part
[16:06] <ubitux> iirc something like 70 out of the 2k+ tests got better
[16:07] <ubitux> but since one of the main core threading code make these tools choke
[16:07] <aetasx> I'll have to wait like a couple hours for testdisk to fix my stupidity before I can look at any of those
[16:07] <ubitux> most of the tests triggers the flood
[16:07] <wm4> ubitux: haha, looking at the first reported data race, helgrind seems to be right
[16:07] <wm4> it's about accessing something called p->state
[16:07] <ubitux> yes
[16:08] <wm4> which at one point is accessed under a progress_mutex held, but in another place at the code without
[16:08] <ubitux> yeah that's what i observed as well
[16:08] <ubitux> but the whole thing is generally protected by "mutex"
[16:08] <ubitux> which frame the whole function generally
[16:08] <ubitux> so i don't know
[16:08] <ubitux> i'm having a hard time what's going on here honestly
[16:09] <ubitux> if we can shut up these warnings, i'm pretty sure we can shut up most of the helgrind complains
[16:10] <ubitux> it's also strange to me to see waiting loop around condition variables
[16:10] <wm4> actually reading the code, this is some sort of double-checked locking
[16:10] <wm4>         if (p->state != STATE_INPUT_READY) {
[16:10] <wm4>             pthread_mutex_lock(&p->progress_mutex);
[16:10] <wm4>             while (p->state != STATE_INPUT_READY)
[16:10] <ubitux> yes
[16:10] <wm4> pretty sure this is a bad idea
[16:11] <ubitux> and you have a pthread_mutex_lock() on p->mutex, framing the whole function (sometimes.)
[16:11] <wm4> in this particular case, removing the outer if should fix it
[16:11] <ubitux> honestly, feel free to send patches for this
[16:14] <aetasx> whats setting p->state to break out of that loop in that example?
[16:16] <aetasx> seems odd to see it start blocking on the mutex and then get out of it and go right back into waiting on something else again
[16:17] <wm4> another thread
[16:18] <wm4> condition variables
[16:18] <aetasx> to account for any sort of race condition between when the thread unlocks the mutex?
[16:20] <aetasx> Im still waiting on my drive repair so I'm somewhat blind as far as looking up the related code
[16:20] <aetasx> thank god for testdisk though
[16:21] <Compn> what size disk are you testing aetasx ?
[16:22] <aetasx> 1TB raid array
[16:23] <aetasx> was moving a partition around and it failed mid-way so I used it to find the partitions got lost
[16:25] <aetasx> that tool beats out any form of commercial stuff I've tried to use.  the only ones that let you really work with them at a low level are all linux tools
[16:33] <wm4> ubitux: there are several places where p->state is (apparently) intentionally accessed without mutex, so I'm not very confident about moving them in
[16:36] <wm4> hm code was authored by Alexander Strange
[16:38] <iive> that should be beastd
[16:39] <ubitux> astrange ` beastd
[16:42] <ubitux> akira4: ok so
[16:43] <ubitux> afaict, the libdvd*, even dvdread, is actually really low level
[16:43] <ubitux> and don't even give you information on the stream themselves
[16:44] <ubitux> akira4: did you branch out master with the original patch from Stefano?
[16:44] <ubitux> and check what you can get from it
[16:57] <iive> ops. mybad
[17:03] <wm4> <ubitux> and don't even give you information on the stream themselves <- they probably give you what's in the dvd on-disk structures, but don't parse the mpeg streams themselves (maybe)
[17:04] <ubitux> yeah i mean, it doesn't seem to provide enough abstraction to create an AVPacket from it
[17:04] <ubitux> like, it doesn't seem trivial to create the streams yourself from the info the libs give you, and map the data you get from the lib to your AVPackets
[17:05] <ubitux> like i initially though
[17:05] <ubitux> +t
[17:06] <wm4> mapping the mpeg streams to what dvdread provides can be messy, yes
[17:07] <ubitux> so the protocol might actually be the way to go
[17:07] <wm4> you have to map them anyway at some point
[17:08] <ubitux> are dvd always mpeg2 with ac3?
[17:08] <wm4> no
[17:08] <nevcairiel> they can be mp2 audio, or even dts
[17:08] <nevcairiel> but its super rare
[17:08] <wm4> I think there are dvds with pcm too
[17:08] <ubitux> still possible then
[17:08] <nevcairiel> oh yeah pcm too
[17:08] <nevcairiel> even a special pcm_dvd codec in avcodec
[17:11] <ubitux> so yeah, "protocol" is the way to go
[17:11] <BBB> the state accesses suppose that integers are atomic
[17:11] <BBB> that is not guaranteed in c, although it happens to be true on most archs, e.g. x86
[17:12] <BBB> feel free to change them to atomic ints if you want to be c compliant
[17:12] <ubitux> don't we have an atomic api for that?
[17:12] <BBB> we didnt back then when he wrote it
[17:13] <BBB> a lot of opensource programmers think that writing a lib or api solves all problems; it only does, if you port all software to use the new api/lib
[17:13] <wm4> BBB: is there any reason not just to access this state under a mutex?
[17:13] <BBB> too much overhead
[17:14] <BBB> grabbing a mutex is actually a really heavy operation, and these are called per macroblock
[17:14] <BBB> try it, I saw a patch doing that when I worked on chrome
[17:14] <BBB> someone using some automatic tool found the errors
[17:14] <BBB> I think it was 5-10% slower
[17:15] <BBB> and so I recommended they dont even try to push that patch upstream, because why waste your time and energy on something pointless
[17:15] <ubitux> don't we already have mutexes around most state accesses?
[17:15] <BBB> nobody wants to lose 5-10% performance for no benefit other than making helgrind happy
[17:15] <wm4> BBB: what if it finds new bugs in turn
[17:15] <BBB> then do it only when running udner that tool
[17:15] <BBB> which is very dangerous in itself
[17:16] <BBB> as soon as you get a tool to run different code than what the user runs& the tool becomes useless in finding actua errors in that code
[17:16] <BBB> (its one of the reasons I dont like our bitexact flags)
[17:17] <BBB> (in fate)
[17:17] <ubitux> using the atomic api should be a no-op with most compilers, right?
[17:17] <nevcairiel> i think there is actually different instructions that get used
[17:18] <BBB> with atomic, yes
[17:18] <BBB> ubitux: yes
[17:18] <ubitux> and if we use this atomic api, can we get rid of all the mutexes dance in this file?
[17:18] <ubitux> "all" is a bit much
[17:19] <ubitux> let's say "a lot of" around state
[17:19] <nevcairiel> if all its used for is to access a single state variable, possibly
[17:19] <ubitux> the progress ones seems to be related to that
[17:19] <ubitux> but i can't tell; state seems protected by both p->mutex and p->progress_mutex
[17:20] <ubitux> but not properly all the time apparently
[17:20] <nevcairiel> lock-free thread interaction gives me headaches though
[17:20] <ubitux> :confuse:
[17:20] <BBB> particular transitions are protected by different mutexes
[17:20] <BBB> iirc
[17:24] <akira4> ubitux, so then what do I do? I have the patch but I haven't branched master and applied it.
[17:25] <ubitux> akira4: try to do that, it will be useful whatever you do later
[17:25] <ubitux> like, try to make that patch work
[17:25] <akira4> okay. I'll do that. Did you try to read and ISO file with the diff I gave ?
[17:25] <akira4> *an
[17:26] <ubitux> no; it works?
[17:26] <akira4> I get a segfault when the playback stops. I can't figure out why.
[17:27] <ubitux> i'm looking at the original dvd patch currently (trying to apply it myself)
[17:27] <ubitux> to check a bit more what you'll need to do on it
[17:27] <ubitux> assuming we use it as a base
[17:36] <ubitux> akira4: the patch seems to "work" for me
[17:36] <ubitux> https://github.com/ubitux/FFmpeg/compare/dvdprotocol
[17:37] <ubitux> it crashes randomly, isn't able to seek, doesn't see any subtitles stream, but... it somehow playbacks things
[17:37] <akira4> hmmm..
[17:38] <akira4> so then I'll try fixing this patch then ( I guess ?)
[17:42] <akira4> ubitux, I get some errors when trying to apply the patch. Its the patch that you gave the link to right?
[17:43] <ubitux> you should have no problem applying the patch from the branch i just pasted
[17:43] <ubitux> git remote add ubitux git at github.com:ubitux/FFmpeg.git
[17:43] <ubitux> git fetch ubitux
[17:44] <ubitux> go into your branch, and git cherry pick ubitux/dvdprotocol
[17:44] <ubitux> should do it
[17:44] <akira4> okay. thanks 
[17:47] <ubitux> you should probably drop the self alloc and stuff
[17:49] <ubitux> which fixes the crash for me
[17:49] <ubitux> but i still see no subtitles stream
[17:52] <ubitux> anyway, try to play with this
[17:55] <akira4> okay.
[18:12] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:3b1f747238d6: avfilter/vf_cropdetect: add max_outliers parameter
[18:26] <akira4> ubitux, I tried the patch. In my case the video plays abruptly but I see the subtitles .And  what about the DVD input device then ?
[18:28] <ubitux> what's your ffprobe output?
[18:28] <ubitux> the input device might not be the best decision since libdvd* are too low level
[18:30] <akira4> well, the ffprobe gave some errors because of some missing parameters first. When I tried to read the data packets I got a segfault.
[18:30] <akira4> so basically everything was going wrong :'(
[18:33] <akira4> I was hoping that if I could resolve the segfault problem then maybe I could get a proper ffprobe output.
[18:37] <ubitux> 17:47:59 <@ubitux> you should probably drop the self alloc and stuff
[18:37] <ubitux> 17:49:12 <@ubitux> which fixes the crash for me
[18:38] <JEEBsv> fun times with AAC broadcasts https://fushizen.eu/u/jeeb/out-intare.ts
[18:39] <JEEBsv> (the 5.1 part seems borked)
[18:41] <akira4> ubitux, I'm not sure what you meant by self alloc?
[18:41] <ubitux> BBB: the atomic get is a no-op, but the atomic set calls mfence on here on x86
[18:41] <ubitux> akira4: the allocation of the local DVD context
[18:41] <ubitux> akira4: what you removed in your patch a few days ago
[18:42] <nevcairiel> set has to use a memory barrier to avoid simultaneous writes on different cores
[18:42] <ubitux> so in practice it's actually necessary
[18:43] <ubitux> but only for write
[18:43] <nevcairiel> thats on x86 anyway, other systems may require something for get as well
[18:46] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:beaea2de61c8: avdevice/dv1394: Use av_freep() to avoid leaving stale pointers in memory
[18:46] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:a3f6e8c4d926: avdevice/dshow: Use av_freep() to avoid leaving stale pointers in memory
[18:46] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:9c3a8693a20d: avdevice/dshow: Remove unneeded NULL checks
[18:51] <akira4> ubitux, regarding the ffprobe o/p I was talking about my patch not Stefano's patch. 
[18:51] <ubitux> focus on stefano's one
[18:53] <akira4> alright.
[19:11] <ubitux> http://pastie.org/pastes/9802400/text
[19:11] <ubitux> BBB, nevcairiel ^
[19:12] <ubitux> so on arm at least, both read and write aren't atomic
[19:12] <ubitux> so the current code could fail there, right?
[19:12] <nevcairiel> fail is a relative term, it may be more vulnerable to race conditions
[19:13] <ubitux> yes
[19:13] <ubitux> so it basically means it's not reliable
[19:20] <wm4> I think the current code relies that the writes get through eventually
[19:20] <wm4> which might be true?
[19:21] <BBB> you guys miss the important questions
[19:21] <BBB> a) does it fix an actual, real issue
[19:21] <BBB> b) is it slower
[19:21] <BBB> depending on a trade-off between these two, the patch may or may not be acceptable
[19:22] <wm4> who can really answer a)?
[19:24] <BBB> well, why are you workign on this
[19:24] <BBB> it suggests youre trying to implement a feature requestor fix a reported bug
[19:24] <BBB> right?
[19:24] <BBB> or did you just stumble on the code and you couldnt stop wondering whether there was a race condition and it lead to this discovery?
[19:24] <BBB> or did you trust helgrind or related tools?
[19:25] <BBB> or something else?
[19:42] <ubitux> BBB: the real issue is that it this potential issue is hidden many potential other issues and make these tools useless
[19:42] <ubitux> just like 999 uninitialized read with no visible consequences could hide 1 real one
[19:43] <ubitux> i'm not familiar enough with the code to know what to do to show the issue; like, i could add some sleep randomly
[19:43] <ubitux> i would need to test on arm instead of x86
[19:43] <ubitux> or such thing
[19:43] <ubitux> which is hard to test
[19:47] <ubitux> it's really annoying to not be able to know if we aren't doing anything wrong when writing threading code
[19:47] <ubitux> and i consider this a real issue and hindrance in development
[19:48] <ubitux> now of course the performance issue is a concern 
[19:49] <ubitux> but closing our eyes until it explodes doesn't look like the appropriate approach :p
[19:51] <wm4> sometimes debugging tools produce far more false positives than useful results
[19:51] <wm4> don't know if helgrind is such a tool, though
[19:54] <ubitux> well
[19:55] <ubitux> wheither it's tsan, drd or helgrind
[19:55] <ubitux> they all complain a lot about the same thing
[19:55] <wm4> heh
[19:56] <ubitux> btw
[19:56] <ubitux> using atomics for every state access doesn't help
[19:56] <ubitux> it still complains
[19:57] <wm4> well it doesn't know that these are atomics
[19:57] <wm4> (probably)
[19:57] <wm4> especially if the atomic access compiles to the same code as non-atomic
[19:58] <BBB> ubitux: tsan is helgrind
[19:58] <BBB> ubitux: its the same tool
[19:59] <BBB> (I know thats weird, but I asked the author once and he said its basically helgrind)
[19:59] <ubitux> ok
[19:59] <BBB> so...
[19:59] <BBB> I know that for atomics, helgrind has special accessors
[20:00] <BBB> basically macros that mark them as HI I AM AN INVALID ACCESS ACCORDING TO THIS RETARDED TOOL, BUT ITS OK SO PLEASE DONT SAY ANYTHING
[20:00] <wm4> so it substitutes its own stdatomic.h?
[20:00] <BBB> if you hook these up in libavcodec(?)s atomic code, they should go away
[20:01] <BBB> we already have separate implementations for gcc and msvc and anything else"
[20:01] <BBB> this would just be another implementation
[20:01] <BBB> but anyway, if you use these special accessors, the warnings do go away for that once tool
[20:01] <BBB> s/once/one/
[20:02] <BBB> if you have a real threading bug, Id love to have a look, I love these bugs
[20:02] <BBB> that reminds me I should writeup my libswresample optimizations at some point on my blog
[20:12] <ubitux> ok so, adding atomic get/set for p->state and p->die, and forcing HAVE_ATOMICS_NATIVE to 0 make all the issues go away with the random command line i tried
[20:12] <ubitux> but now i'm trying with a h264 video
[20:13] <ubitux> and i get many others
[20:13] <ubitux> http://pastie.org/pastes/9802491/text such as this
[20:16] <cehoyos> BBB: Isn't this a threading bug? http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-threads
[20:24] <BBB> not a race condition
[20:24] <BBB> I can fix it if you want, but I dont work on hevc much so far
[20:28] <cehoyos> I am just wondering because it only happens on one machine...
[20:32] <Zeranoe> Am I correct to assume that libshine uses some lame components and it's either one or the other in a build?
[20:34] <Zeranoe> and if that is the case, which should be included in the Windows builds?
[20:37] <cehoyos> Definitely lame.
[20:40] <cone-53> ffmpeg.git 03Simon Thelen 07master:750b10ff85d4: doc/ffmpeg.texi: document the new -sdp_file option
[20:48] <cehoyos> Did anybody ever test "AJA Kona 10-bit RGB Codec"? Is it really likely that there is a difference between "R10k" and "r10k"?
[21:44] <cone-53> ffmpeg.git 03Carl Eugen Hoyos 07master:6a6a0620e2f8: Fix R10k blue channel output.
[22:00] <ubitux> http://ubitux.fr/pub/pics/_the-simple-formula.png 
[22:01] <ubitux> mathematicians know how to make you feel dumb
[22:01] <cone-53> ffmpeg.git 03Pedro E. M. Brito 07master:202947a0665e: libavformat/segment.c: Add strftime expansion for segment filename templates
[22:42] <kierank> av500: http://events.ccc.de/congress/2014/Fahrplan/events/6156.html
[22:42] <kierank> quite interesting
[23:15] <kierank> michaelni: can the interlaced flag just be set to default in the scale filter?
[23:25] <michaelni> maybe
[23:30] <Daemon404> ubitux, is that from wikipedia?
[23:30] <Daemon404> they just really like to wank over eq'ns
[23:30] <ubitux> no, "the" paper
[23:31] <Daemon404> well, >academic papers
[23:31] <Daemon404> must make it as inpenetrable as possible
[23:44] <kierank> 10:25 PM <"michaelni> maybe --> ?
[00:00] --- Mon Dec 29 2014