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

[burek]

[03:17] <cone-556> ffmpeg.git 03Michael Niedermayer 07b6a7f66f9329: resample: remove disabled debug code
[03:17] <cone-556> ffmpeg.git 03Michael Niedermayer 07bde6f6eadc24: vc1dec: prevent v_edge_pos from becoming negative.
[03:17] <cone-556> ffmpeg.git 03Michael Niedermayer 07d7169280a649: frame_thread_encoder: fix locking while locks are held
[03:17] <cone-556> ffmpeg.git 03Michael Niedermayer 07eed865540af8: Revert "Add assert that the avcodec lock is held when initializing static VLC tables."
[03:17] <cone-556> ffmpeg.git 03Michael Niedermayer 070393cf15dbe3: Revert "Acquire lock when initializing parsers."
[03:17] <cone-556> ffmpeg.git 03Michael Niedermayer 072dec950f4904: avcodec_open: if obtaining a lock fails, dont attempt to unlock it.
[03:17] <cone-556> ffmpeg.git 03Michael Niedermayer 077885fa7685c0: ff_lock_avcodec: make the lock state be consistent in case of failure.
[05:00] <cone-556> ffmpeg.git 03Janne Grunau 0724c62ea7a5df: h264: slice-mt: get last_pic_dropable from master context
[05:00] <cone-556> ffmpeg.git 03Janne Grunau 073ab5f7dc1374: h264: slice-mt: check master context for valid current_picture_ptr
[10:17] <cone-556> ffmpeg.git 03Stefano Sabatini 0789920387da8b: examples: add resampling_audio.c file
[10:17] <cone-556> ffmpeg.git 03Stefano Sabatini 07e8278b9d565f: doc/decoders: fix typo in "@Options"
[10:36] <ubitux> what is the 'm' suffix for with yasm? like movd m0, foobarm?
[10:37] <ubitux> why not d?
[11:03] <mateo`> is the prores codec supposed to store somewhere information about the display aspect ratio ?
[11:14] <kierank> probably has a sar somewhere
[11:15] <pross-au> inside the video codec?
[11:20] <mateo`> sar and dar are reported as 0:1
[12:13] <cone-556> ffmpeg.git 03Clément BSsch 070f65d5608011: Add examples/resampling_audio to .gitignore.
[19:16] <durandal_1707> wm4: i do not know is it already reported
[19:17] <durandal_1707> wm4: do you want ffplay issue fixed, if not than who cares :)
[19:19] <wm4> sure, just to see how it's fixed by whoever cares
[20:06] <michaelni> wm4, about ffplay audio que, ask marton, he maintains ffplay
[20:08] <michaelni> Marton Balint | cus at passwd dot hu
[20:08] <michaelni> he isnt on IRC AFAIK
[20:15] <wm4> is it safe to use libavformat from different threads? (if you protect the format context by a single lock)
[20:17] <cone-556> ffmpeg.git 03Paul B Mahol 07586c2528a097: dxa: port to bytestream2 API
[20:19] <michaelni> wm4, make sure you set a lock manager
[20:19] <michaelni> several functions need it
[20:19] <michaelni> like *find_stream_info
[20:19] <michaelni> as it opens decoders which need a lock
[20:20] <michaelni> and currently parsers can get openened from av_read_frame() which too needs a lock, this is what reimar and i work on atm
[20:21] <michaelni> that is, if you set a lock manager, there should be no problems with multiple threads
[20:22] <michaelni> otherwise its a bit tricky currently
[20:22] <wm4> how do you set a lock manager?
[20:22] <michaelni> see ffplay.c for example
[20:22] <michaelni> av_lockmgr_register()
[20:23] <wm4> and what for is that needed... is there mutable global data?
[20:23] <michaelni> decoders and parser have some global data that gets initialized when they are opened
[20:24] <michaelni> most of the code is thread safe actually but not all 
[20:24] <wm4> and I don't see the point... why not just call pthread_* directly inside of ffmpeg?
[20:25] <michaelni> you mean inside of libavcodec, its not guranteed that thread systems can be mixed liek that
[20:26] <michaelni> that is a user app creating therads with one system like SDL, w32 or whatever
[20:26] <wm4> and? locks are locks, they always work
[20:26] <michaelni> and pthread mutexes might cause problems
[20:27] <wm4> how so?
[20:28] <michaelni> in previous discussions it was stated that they dont always work when mixed or arent guranteed to
[20:30] <michaelni> i can only guess what problems might exist when they are mixed, i dont have first hand knowledge of this
[20:30] <wm4> I would understand that if the threading usage was more sophisticated than just locks
[20:31] <wm4> I'd say this should be fixed by choosing the thread API at build-time
[20:31] <wm4> not adding hilarious broken hacks
[20:32] <wm4> but that's just me
[20:32] <michaelni> if you build statically this sure would make sense
[20:32] <michaelni> but for shared distro installed libs its not so easy
[20:32] <michaelni> they might be used from apps that use different thread apis
[20:36] <michaelni> either way its close to the top of my todo list to fix some of the thread non safe code
[20:37] <ubitux> what's on top? :)
[20:37] <wm4> apropos threads, why is some code in pthread.c checking for avcodec_default_get_buffer?
[20:38] <wm4> it compares avctx->get_buffer with it; why would that matter?
[20:38] <wm4> a custom get_buffer could just be calling avcodec_default_get_buffer
[20:38] <wm4> or it could be doing something that conforms to avcodec's requirements on get_buffer
[20:38] <michaelni> it can set thread_safe_callbacks in that case
[20:40] <michaelni> ubitux, as its just a list in my mind thats not so easy to awsner :)
[20:40] <ubitux> :)
[20:41] <wm4> michaelni: oh I see, makes sense
[21:02] <ubitux> saste learned kage bushin no jutsu
[21:02] <ubitux> bunshin*
[21:03] <ubitux> saste: need help for the volume merge?
[21:03] <saste> uhm i'm duplicated again
[21:03] <saste> let's try with an xchat restart...
[21:05] <saste> uhm another user with the same name??
[21:05] <ubitux> 21:01:54 ::: saste [~saste___ at dynamic-adsl-78-15-172-238.clienti.tiscali.it] has joined #ffmpeg-devel
[21:05] <ubitux> 21:01:56 ::: saste_ [~saste___ at dynamic-adsl-78-15-172-238.clienti.tiscali.it] has joined #ffmpeg-devel
[21:05] <saste> ubitux: how are the two filters different?
[21:05] <saste> volume_justin has ASM optims and a different syntax, right?
[21:05] <ubitux> saste: you need to add a shorthand
[21:05] <ubitux> merge documentation
[21:06] <ubitux> and remove the av_log() on syntax error
[21:06] <ubitux> afaik that's all that is needed
[21:06] <saste> ubitux: what filter should we drop?
[21:06] <ubitux> our
[21:06] <Daemon404> i have a random lavfi question: is each filter still responsible for parsing it's own options string?
[21:06] <Daemon404> i.e. tons of duplicated strign parsing code
[21:07] <saste> ok
[21:07] <ubitux> Daemon404: no
[21:07] <Daemon404> oic
[21:07] <ubitux> AVOption
[21:07] <Daemon404> ubitux, last time i checked it was
[21:07] <Daemon404> (while porting to msvc)
[21:07] <ubitux> AVOption + shorthands in ffmpeg
[21:07] <Daemon404> is this a recent development?
[21:07] <wm4> sscanf rocks (not)
[21:07] <ubitux> Daemon404: shorthands are recent yes
[21:07] <ubitux> Daemon404: look at libavfilter/vf_tile.c
[21:08] <ubitux> line 50-75
[21:08] <Daemon404> wm4, as much as c++ is derp, it's strng stuff is nice
[21:08] Action: Daemon404 runs for his life
[21:08] <ubitux> we have bprint API for strings
[21:09] <Daemon404> https://github.com/dwbuiten/d2vsource/blob/master/core/d2v.cpp#L196 <-- stuff like this is nice
[21:09] <wm4> there's only one thing worse than crappy C code: trying to fix crappy C code by throwing C++ at it
[21:09] <Daemon404> wm4, i basically use c++ as "c with strings"
[21:10] <ubitux> Daemon404: basically, the new syntax allow various things:
[21:10] <saste> wm4, is this an argument to switch to C++?
[21:10] <ubitux> tile=3x2:nb_frames=5:padding=7:margin=2
[21:10] <wm4> oh dear, stringstream
[21:10] <ubitux> tile=layout=3x2:nb_frames=5:padding=7:margin=2
[21:10] <saste> C++ has a lot of compat problems and design glitches
[21:10] <Daemon404> wm4, do you have a valid complaint or just "it's stringstream"
[21:10] <ubitux> tile=3x2:5:7:2
[21:10] <ubitux> all of this is the same thing
[21:10] <Daemon404> saste, yes it does, but thats not what i was advocating
[21:10] <Daemon404> if you read.
[21:11] <saste> that's what happens when you try to nail additional legs to a dog
[21:11] <wm4> just that iostream is horrible design and that you could as well write C functions that do the same in a less appalling way
[21:11] <Daemon404> wm4, 'horrible design' is very vague
[21:12] <ubitux> it means it sucks
[21:12] <ubitux> but decently said
[21:12] <Daemon404> yes we dont need any facts here
[21:12] <Daemon404> just hearsay
[21:12] Action: wm4 wonders if that code does error handling
[21:12] <bcoudurier> hey guys
[21:12] <Daemon404> wm4, it's currently a hack
[21:13] <wm4> Daemon404: I'd still prefer that code over sscanf any day, though
[21:13] <Daemon404> wm4, i chose it over sscanf specifically
[21:13] <cone-556> ffmpeg.git 03Clément BSsch 07bbd44f6ca4ba: lavfi/mp: switch to ff_filter_frame.
[21:13] <Daemon404> or manualy string stuff
[21:13] <Daemon404> with pointers
[21:13] <wm4> sscanf is the worst function that exists in C (after gets())
[21:13] <michaelni> hi bcoudurier 
[21:13] <JEEB> ugh, sscanf
[21:16] <wm4> stringstream probably makes it harder to guess how the code behaves on "tricky" input than sscanf
[21:16] <Daemon404> libavfilter$ grep sscanf vf_*.c | cut -d":" -f1 | sort | uniq | wc -l
[21:16] <Daemon404> 25
[21:16] <Daemon404> wm4, it does.
[21:16] <Daemon404> so eah
[21:17] <Daemon404> tons of sscanf/parsing in filters still
[21:17] <Daemon404> :)
[21:17] <wm4> on to eternal refactoring
[21:17] <Daemon404> o/
[21:18] <ubitux> Daemon404: we should be able to drop some
[21:18] <ubitux> Daemon404: it some case it's simple btw
[21:18] <ubitux> look at thumbnail, there is just one %d to parse
[21:18] <wm4> too bad that the command stuff in lavfi encourages/requires manual string parsing yet again
[21:19] <wm4> and it certainly requires host applications to generate these strings
[21:19] <ubitux> command parsing?
[21:19] <ubitux> just re-call the re-init
[21:19] <Daemon404> wm4, and some filts want you to parse av_log stuff =p
[21:19] <Daemon404> as outout
[21:19] <Daemon404> output(
[21:19] <wm4> Daemon404: sglkjasklgha
[21:20] <wm4> I guess lavfi is mainly developed for use with "ffmpeg" and "ffplay"
[21:20] <Daemon404> wm4, i had a big thread about lavfi's issues a while back
[21:20] <saste> Daemon404, wm4: what we lack is not ideas about how to improve things, but patches ;-)
[21:20] <Daemon404> some are being addressed
[21:20] <Daemon404> constructively ;)
[21:21] Action: Daemon404 has no motivation to work on lavfi himself, obviously
[21:21] <Daemon404> aside: i should really send some of my backlogged patches to the ML
[21:22] <saste> ubitux: ping on tinterlace patch
[21:23] <ubitux> saste: ah right, forgot to review
[21:23] <ubitux> saste: give me a few minutes
[21:25] <Daemon404> saste, is there more of filters.texi coming?
[21:26] <Daemon404> texi2html is barfing warnings
[21:26] <saste> Daemon404, I know
[21:28] <ubitux> saste: done
[21:30] <ubitux> what's going to happen to cur_buf?
[21:30] <ubitux> will we drop it from all the filters?
[21:49] <michaelni> ubitux, is it or the other 2 usefull for something without slices ?
[21:50] <ubitux> i think we can make use of out_buf in a lot of filters
[21:50] <ubitux> to avoid requesting manually a buffer
[21:51] <ubitux> cur_buf, no idea
[21:51] <ubitux> i don't see the usage
[21:53] <cone-556> ffmpeg.git 03Michael Niedermayer 074b6869d6e012: bitstream: make vlc init of static tables thread safe.
[21:54] <michaelni> ubitux, whats usefull should be kept, whats useless should be droped
[21:56] <ubitux> sounds legit :)
[21:56] <michaelni> wm4, demuxers from multiple threads without a lock manager might work now, that is av_read_frame() but theres alot of code so its hard to say for certain that theres nothing thread unsafe left somewhere
[21:57] <Daemon404> hmm
[21:57] <Daemon404> is it possible to tell ffmpeg cli to skip negative timestamps?
[22:00] <ubitux> -avoid_negative_ts?
[22:03] <Daemon404> -avoid_negative_ts <int>   E..... avoid negative timestamps
[22:03] <Daemon404> gee that's a good explanation...
[22:03] <Daemon404> if only i knew what it did now.
[22:04] <ubitux> it affects muxers
[22:04] <ubitux> muxers decide to honor it or no
[22:04] <Daemon404> thats not what i want
[22:04] <Daemon404> i want to completely drop any frame with negative ts
[22:04] <Daemon404> encoder/muxer never see it
[22:04] <ubitux> mmh
[22:04] <ubitux> -vf select?
[22:05] <ubitux> -vf 'select=gte(PTS\,0)' or something like that?
[22:05] <Daemon404> does select affect speed or mem usage a lot?
[22:05] <ubitux> "pts", not "PTS" sorry
[22:05] <ubitux> Daemon404: you need to decode/encode
[22:06] <Daemon404> ?
[22:06] <Daemon404> you need to decode/encode anyway... thats why it's called transcoding
[22:06] <ubitux> then it should not be slower
[22:09] <cone-556> ffmpeg.git 03Michael Niedermayer 07656500c503f6: lavf: improve help text for avoid_negative_ts
[22:10] <Daemon404> ubitux, thanks
[22:10] <Daemon404> that seems to be right
[22:11] <ubitux> aren't you ashamed to use lavfi?
[22:11] <Daemon404> dont worry, this is temporary :P
[22:11] <ubitux> i'm relieved then
[22:11] <kierank> Daemon404: x264 outputs negative dts
[22:11] <Daemon404> a lot of it?
[22:12] <Daemon404> kierank, the problem im having some things have liek 10-20 frames with negative pts
[22:12] <Daemon404> that are supposed to not be displayed
[22:12] <Daemon404> title cards etc
[22:12] <Daemon404> from "pro" apps
[22:12] <ubitux> michaelni: "timsstamps" typo
[22:12] <ubitux> thanks for the doc :)
[22:12] <kierank> Daemon404: only two frames
[22:13] <ubitux> michaelni: it might have been wise to update doc/ffmpeg-formats.texi too/instead
[22:13] <Daemon404> kierank, no
[22:13] <Daemon404> or
[22:13] <Daemon404> ok
[22:13] <Daemon404> kierank, but pts is what i care about, not dts
[22:14] <Daemon404> negative dts should be fine
[22:17] <Daemon404> ubitux, !!
[22:17] <ubitux> !!
[22:17] <ubitux> yes?
[22:17] <Daemon404> you gave me the idea to use vf select to handle multipel edit list entries (parsing l-smash's boxdumpter output to get frame ranges)
[22:17] <Daemon404> \o/
[22:18] <ubitux> and soon you're going to become a lavfi fanboy
[22:18] <Daemon404> nah
[22:18] <Daemon404> cause it's still easier in VS :P
[22:18] <ubitux> don't be shy
[22:18] <Daemon404> ;p
[22:19] Action: Daemon404 is not a tsun
[22:20] <ubitux> :D
[22:20] <ubitux> they all say that
[22:42] <ubitux> mmh i think there is a problem with the mmx code in gradfun
[22:42] <ubitux> beside the dithering which i fixed
[22:48] <cone-556> ffmpeg.git 03Stefano Sabatini 07fef7b2e0bef6: lavfi/tinterlace: switch to filter_frame API
[22:48] <cone-556> ffmpeg.git 03Stefano Sabatini 07c6a216771fa2: lavfi/tinterlace: add support to option parsing
[22:48] <cone-556> ffmpeg.git 03Stefano Sabatini 07da9a45b68152: lavfi/tinterlace: drop redundant NULL checks in uninit()
[22:56] <saste> ubitux: PRESERVE should not be needed by tinterlace
[22:56] <ubitux> ah?
[23:17] <cone-556> ffmpeg.git 03Michael Niedermayer 07892750b07bd0: fix tipo
[23:17] <ubitux> haha
[23:19] <ubitux> you have a typo in your tipo
[00:00] --- Fri Dec  7 2012