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

[burek]

[00:04] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:bf2ce19e51fd: avcodec/hevc: Dont turn 32bit timebases into negative numbers
[00:04] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:d1e6602665d5: avcodec/hevc: make *ps_id unsigned
[00:13] <BBB> ubitux: I'm getting closer to having intra pred simd ready
[00:13] <BBB> (that is, simd is written but dr 16x16 is broken, 32x32 untested and all of vl/vr/hu/hd are also untested - the rest works)
[00:14] <ubitux> cool :)
[00:14] <ubitux> i'm working on some other random ffmpeg work for a third party :p
[00:14] <nevcairiel> i hope they pay you
[00:16] <ubitux> they can't actually i have no legal status for that :]
[00:48] <Compn> cant they send you money in an envelope ? :P
[01:01] <kierank> Compn: holland will take his money
[01:45] <ubitux> i don't mind the taxes
[01:45] <ubitux> i do mind the paperwork though
[01:46] <ubitux> so i'd better not see the money at all :)
[01:48] <BBB> crazy europeans
[01:48] <michaelni> ubitux, just pay someone to do the paperwork if you dont want to do it yourself
[01:49] <Compn> do that and then donate your money to charity :P
[01:49] <ubitux> Compn: that's somehow what i do
[01:49] <ubitux> either i ask for hw, or i ask for donation
[01:49] <ubitux> (ffmpeg or random charity i care about)
[01:50] <ubitux> speaking of the ffmpeg donation i wonder if that one reached it, i should nag saste about it
[01:50] <Compn> ah :)
[01:50] <ubitux> anyway, 'night
[01:50] <Compn> night
[01:50] <michaelni> night
[01:53] <ubitux> (michaelni: ah, and well, i don't do enough payed mission to consider this, that's really too punctual - my full time job is enough for income)
[01:56] <Compn> we just like to bug you ubitux :)
[01:56] <Compn> ehe
[01:56] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:e5c722999918: avcodec/utils: set AVFrame format unconditional
[02:04] <cone-776> ffmpeg.git 03Tim Walker 07master:9c0e4b3395ca: ac3: update AC3PreferredStereoDownmixMode.
[02:04] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:fdf8b59b28cb: Merge commit '9c0e4b3395cad79c560d03d2a94595d89e017885'
[02:10] <burek> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=1276 -> ohmk: "Thanks logan, reading your replies around here, you are a huge contributor to this community and I'm sure I speak for everyone that we all appreciate your responses."
[02:10] <burek> I also wanted to say thank you for your huge contribution llogan :) :beer: :)
[02:12] <Compn> llogan works hard :)
[02:19] <cone-776> ffmpeg.git 03Tim Walker 07master:c98f3169bfb5: lavu: add AV_FRAME_DATA_DOWNMIX_INFO side data type.
[02:19] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:a2bc6c116ddc: Merge commit 'c98f3169bfb578c1a4e407b44524f0bfa3b4dc0c'
[02:25] <cone-776> ffmpeg.git 03Tim Walker 07master:9cd4bc41760f: ac3dec: set AV_FRAME_DATA_DOWNMIX_INFO side data.
[02:25] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:1db87da35141: Merge commit '9cd4bc41760f8ad879e248920eacbe1e7757152c'
[02:30] <cone-776> ffmpeg.git 03Reinhard Tartler 07master:f58dcfb32e0f: Prepare for 10_beta1 Release
[02:31] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:bbd8fd0371a5: Merge remote-tracking branch 'qatar/master'
[03:10] <cone-776> ffmpeg.git 03Hendrik Leppkes 07master:45581ed15d2a: oggdec/vorbis: fix stream duration condition
[03:51] <BBB> and right now vl/hd/hu are untested and vr32x32 is broken, rest works
[03:51] <BBB> so 13 to go
[03:51] <BBB> unlucky number
[03:52] <BBB> I guess that means it's time to sleep
[03:52] <BBB> almost there...
[04:14] <cone-776> ffmpeg.git 03Timothy Gu 07master:8fe107609437: doc/ffmpeg: make the ASCII flow charts narrower to fit onto TTY
[08:49] <t355u5> ffmpeg from git shows negative fps and I don't know how to debug this. any tips? here is the output:
[08:49] <t355u5> ffmpeg 2.1.3:
[08:49] <t355u5> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x816, 1976 kb/s, 24 fps, 24 tbr, 24k tbn, 48 tbc (default)
[08:49] <t355u5> git:
[08:49] <t355u5> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x816, 1976 kb/s, -6.10 fps, 24 tbr, 24k tbn, 48 tbc (default)
[12:04] <michaelni> t355u5, look at what avg_frame_rate is set by av_find_stream_info() or before it
[12:07] <t355u5> michaelni: how do I do that? -loglevel debug does not give me much info
[12:08] <michaelni> t355u5, you use a text editor with utils.c
[12:09] <t355u5> michaelni: ok, so the manual way. I'm used to debug code that really gives you all the debg info
[12:10] <t355u5> what about gdb? do you have a brakpoint I could use?
[12:16] <t355u5> michaelni: there are several utils.c files 
[12:17] <michaelni> t355u5, grep for avg_frame_rate, and check where its set to a negative value and why
[12:17] <michaelni> libavformat/utils.c
[12:19] <t355u5> in libavformat/utils.c avg_frame_rate is never set, just accessed/referenced. ok, I'll browse through the code
[13:11] <t355u5> michaelni: ok, the framerate in avformat_find_stream_info is always negative. avg_frame_rate: num: -108839912 den: 17834625
[13:11] <t355u5> michaelni: now I check it before avformat_find_stream_info
[13:20] <t355u5> michaelni: this will take forever, I am not familiar with the code. have to do some other things now.can you at least reproduce the problem, or are your fps correct?
[13:23] <michaelni> t355u5, you would have to provide a sample file and command line to test first
[13:25] <t355u5> michaelni: sure, np. where shall I put it. I cut the file off after 4MB. I can either put it on my server or upload it. the commandline is easy: ffmpeg -i fname.mp4
[13:26] <michaelni> trac
[13:26] <t355u5> ok, I'll open a ticket in the evening. need to grab some breakfast... ttyl
[13:27] <michaelni> you might need to cut it a bit smaller than 4mb though, not sure what the max filesize is or
[13:28] <cone-926> ffmpeg.git 03James Almer 07master:ec482e738ddc: x86/fladsp: add missing check to ff_flacdsp_init_x86()
[13:28] <t355u5> with 1mb, ffmpeg can't read the header. but I try to make it as small as possible. if not, I put it on my server and put a link in the ticket. no worries, no user/pwd. just public http
[13:28] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:18f94df8af04: avcodec/alsdec: check predictor order against block length
[15:42] <BBB> yay all simd works
[15:43] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commits/vp9-simd
[15:45] <BBB> ubitux: can't measure right now b/c I'm watching olympics and that ruins any performance metric
[16:06] <ubitux> BBB: waaa :)
[16:07] <ubitux> do you want me to review on github/irc?
[16:11] <BBB> dunno, probably github is easier b/c then I have a log
[16:11] <BBB> irc will get lost
[16:11] <BBB> pastebin is ok also
[16:12] <BBB> or I can email to the list
[16:13] <BBB> do whatever is easiest for you
[16:13] <BBB> I'll adapt
[16:14] <ubitux> idc
[16:14] <ubitux> i'll review in a few hours
[16:25] <BBB> ty
[17:25] <superware> any idea why AVStream->avg_frame_rate is {0,0} for h264 network streams? how can I reliably get frame rate?
[17:27] <BtbN> superware, use timebase. Look at how libx264 does it.
[17:30] <superware> BtbN: ok, 1.0 / FFmpegInvoke.av_q2d(st->codec->time_base) equals 180000, what does it mean?
[17:32] <BtbN> that something went wrong. timebase is "seconds per frame"
[17:32] <superware> av_q2d(st->codec->time_base) is 0.0000055555555555555558
[17:33] <superware> { den: 180000, num: 1 }
[17:34] <superware> av_q2d(st->r_frame_rate) is half, 90000
[17:35] <BtbN> yes, h264 usualy does two ticks per frame. There's another variable for that.
[17:37] <superware> eh? :)
[17:41] <nevcairiel> many streams simply dont have useful fps information, and the only way to get it is to probe it, but that doesnt work on network streams
[17:46] <superware> nevcairiel: well, I must know the frame rate to sync rendering :|
[17:46] <nevcairiel> thats not always possible, sorry
[17:47] <nevcairiel> you can of course delay start up and read ~20-30 frames first to try to guess the framerate from the timestamps
[17:47] <nevcairiel> but that makes startup slow of course
[17:47] <superware> can't ffmpeg do it automatically? :)
[17:48] <nevcairiel> it usually does, but it must be disabled by something
[17:49] <superware> maybe AVFMT_FLAG_NOFILLIN or AVFMT_FLAG_NOBUFFER?
[17:49] <nevcairiel> if you set those, then it may be the reason
[17:49] <superware> hmm
[17:49] <BBB> superware: you sync rendering by using the timestamps
[17:50] <BBB> superware: not by looking at framerate
[17:53] <superware> after removing AVFMT_FLAG_NOFILLIN, st->r_frame_rate is ~25, should I use it?
[17:53] <ubitux> r_frame_rate is not what you think it is
[17:56] <ubitux> there is not really a reliable way to get the frame rate, and you probably don't need it anyway
[17:58] <superware> should I do something like (current_frame.index - last_frame.index) / (current_frame.pts - last_frame.pts)  ?
[18:01] <cone-926> ffmpeg.git 03Nicholas Robbins 07master:b4d308c04f7a: lavfi: adding dejudder filter to remove judder produced by partially telecined material.
[18:02] <superware> BBB: do you mean pts?
[18:02] <JEEB> yes, that is the presentation time stamp
[18:02] <superware> or best_effort_timestamp
[18:03] <superware> JEEB: and how should I check whether two frames are sequencial (without missing frames in between)?
[18:06] <superware> JEEB? :|
[18:10] <superware> BBB?
[18:21] <BBB> superware: pts
[18:21] <superware> BBB, ok, how should I check whether two frames are sequencial (without missing frames in between)?
[18:22] <BBB> the rtp layer will provide such information
[18:32] <ubitux> BBB: 'done with the review
[18:32] <ubitux> BBB: i didn't "ditto" a lot of comments, but some things i'm pointing out/asking about are present several times
[19:06] <BBB> ubitux: ok, link?
[19:06] <ubitux> BBB: github comments
[19:07] <ubitux> https://github.com/rbultje/ffmpeg/commit/bb84d5cae677ddbb98a9a65c840b51442f6d6c78
[19:15] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:05e9e3342fe1: avformat/mov: fix avg_frame_rate calculation
[19:17] <BBB> ah yes
[19:17] <BBB> responded to most of them
[19:17] <BBB> so ... yes the unrolling in general might help, I'm a fan of small codesize for stuff that is mostly irrelevant for performance purposes
[19:17] <BBB> we'd probably have to measure it to see if it helps or not
[19:18] <BBB> and givent hat we have to look at whole-picture speed and the impact is so small, it might be hard to measure
[19:18] <ubitux> "when it's a branch target"
[19:18] <ubitux> what's that?
[19:19] <ubitux> ok for non-unroll
[19:19] <BBB> branch target means something if .. a else b
[19:19] <BBB> the .. part
[19:20] <BBB> "the result of this is used in a jump statement
[19:20] <BBB> "
[19:20] <BBB> might mean you want to set condition flags rather than make things unnumbered, as opposed to when the result is used in arithmetic, then you might want to not set condition flags
[19:20] <ubitux> ah, conditionnal RET in the middle of the function then?
[19:21] <BBB> what do you mean exactly?
[19:21] <BBB> I'm missing something
[19:21] <BBB> is this re REP_RET?
[19:21] <BBB> the relevant ocmmit is "x86inc: activate REP_RET automatically" from loren
[19:21] <BBB> so we don't have to write it anymore, x86inc.asm does it for us now
[19:23] <ubitux> yes it's still about REP_RET
[19:23] <ubitux> my quote was from the commit you mentioned
[19:23] <ubitux> and the commit was saying it was still necessary "when it's a branch target"
[19:23] <ubitux> i was wondering what it was refering to
[19:25] <BBB> I think a jump target
[19:25] <BBB> like cmp a, b; jg .end; [some code] .end: REP_RET
[19:26] <ubitux> ok
[19:26] <BBB> I don't think we ever use that
[19:26] <ubitux> thanks :)
[19:28] <BBB> michaelni: did you merge the commits from ffmpeg to always use CODEC_FLAG_EMU_EDGE?
[19:29] <BBB> michaelni: and if not, is it possible we accidently merged the patch to remove the fate tests with emu-edge enabled (since some code paths are different with that flag set in ffvp8/ffvp9)?
[19:30] <BBB> hm the codepaths are gone, so I guess the patches were merged then...
[19:30] <ubitux> BBB: vp9_ipred_vl_8x8 is XMM and has 0 for xmm regs
[19:30] <BBB> oops
[19:30] <BBB> fixed
[19:31] <BBB> also label removed (__unused:)
[20:02] <michaelni> BBB, all should be merged, i only remember that there where some chnages to some asm that i didnt merge (91e00c4a785d3f4cd44f1044d3e7b1b34fee8b5c)
[20:14] <llogan> burek: thanks, but i often don't know the answers.
[20:33] <BBB> ubitux: another patch uploaded also
[20:33] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commit/9d32fdd65cbd65c67f3a2d05a8f8462b51d8b137
[20:40] <ubitux> BBB: zomg speed?
[20:44] <cone-926> ffmpeg.git 03Maxim Poliakovski 07master:77fbc0326555: g2meet: validate bpp and bitmasks in the display info
[20:44] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:573a8ce8f94f: Merge remote-tracking branch 'qatar/master'
[20:55] <ubitux> BBB: anyway, you probably want to macrotize those switch case
[20:56] <ubitux> and maybe change "internal" into "generic" or something (that's obviously an internal function)
[21:04] <BBB> ok
[21:05] <BBB> ubitux: it seems faster, it's 5.3sec to decode my sample file now
[21:05] <BBB> used to be 5.5 when I started the simd and 5.4 in between
[21:05] <ubitux> cool :)
[21:20] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:a392bf657015: avcodec/dxtory: fix src size checks
[22:35] <BBB> ubitux: done
[22:35] <BBB> oh done with macro
[22:36] <BBB> internal->generic still to do
[22:36] <BBB> ubitux: done that also
[22:39] <cone-926> ffmpeg.git 03Alexander Strasser 07master:db3c9701f46d: lavf/avio: Introduce avio_find_protocol_name
[22:39] <cone-926> ffmpeg.git 03Alexander Strasser 07master:2b17c7685fd3: ffmpeg_opt: assert_file_overwrite: Work for all file protocol outputs
[22:46] <cone-926> ffmpeg.git 03Alexander Strasser 07master:2218fbe05e6d: doc/APIchanges: Update for new function avio_find_protocol_name
[23:49] <cone-926> ffmpeg.git 03Michael Niedermayer 07master:c919e1ca2ecf: avcodec/msrle: use av_image_get_linesize() to calculate the linesize
[00:00] --- Mon Feb 17 2014