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

[burek]

[00:04:55 CEST] <peloverde> FYI http://vidtechcon.com/
[00:11:49 CEST] <Daemon404> sf is a little far off for me
[00:15:53 CEST] <j-b> nevcairiel: if you have 99.9% of the code, and are the only contributor of those 99.9% of the code, actully, you can.
[00:17:30 CEST] <philipl> Just down the road
[00:17:34 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:e5774f28d158: avcodec/dvbsubdec: Do not stop decoding at a invalid depth
[01:33:56 CEST] <BBB> peloverde: shall I submit same talk I did at webm summit and at vdd?
[01:34:30 CEST] <BBB> I guess thatd be boring
[01:36:26 CEST] <peloverde> I think the talk you did for webm summit would be super good for that conf
[01:36:38 CEST] <peloverde> in particular the quality vs enc cpu stuff
[01:37:47 CEST] <BBB> need a few more slides I guess
[01:37:50 CEST] <BBB> its not quite 3 minutes
[01:37:52 CEST] <BBB> but also not quite 25
[01:38:00 CEST] <BBB> (its 13)
[01:38:17 CEST] <BBB> will they pay for my travel and hotel?
[01:40:20 CEST] <peloverde> I'd email them and ask, I know they wanted to attract speakers who weren't locals
[01:40:52 CEST] <peloverde> team at vidtechcon.com
[08:06:04 CEST] <razzledazzle> trying to build ffmpeg for android, stumbled upon something, how can this be fixed? http://pastie.org/private/1nn6anrcoxidfpu3fjtkng
[12:05:51 CEST] <durandal_1707> ubitux: what's wrong with high frequencies?
[12:06:32 CEST] <ubitux> blinking high peaks 
[12:07:57 CEST] <ubitux> durandal_1707: i'm trying ./ffplay -f lavfi "amovie=$HOME/samples/pachelbel.mp4,asplit=2[out1],showfreqs=mode=bar[out0]" (http://lucy.pkh.me/pachelbel.mp4)
[12:08:07 CEST] <wm4> philipl: so some nvidia cards have hybrid hevc support... is that any useful?
[12:08:27 CEST] <ubitux> durandal_1707: btw you have LINEAR for default mode but it's a scale option
[12:08:43 CEST] <ubitux> (and you probably want "bar" instead of "line" for default, but nitpick)
[12:10:55 CEST] <durandal_1707> ubitux: frequencies are on x axis and db on y axis
[12:10:58 CEST] <cone-803> ffmpeg 03Luca Barbato 07master:4fee11ab05fc: png: Be more informative regarding signature errors
[12:10:59 CEST] <cone-803> ffmpeg 03Hendrik Leppkes 07master:00b5c1966185: Merge commit '4fee11ab05fc8569ef35c0ce86a60375c903eefb'
[12:13:33 CEST] <ubitux> durandal_1707: yes i know, but high frequencies are not supposed to appear with compressed audio, especially not like that
[12:14:01 CEST] <ubitux> (they are blinking and shit, it looks like an overread or something)
[12:14:29 CEST] <ubitux> btw, the magnitudes are not correct for the first samples
[12:15:06 CEST] <ubitux> there is the real part of the last sample in position 1
[12:15:22 CEST] <ubitux> (complex for first & last are assumed to be 0)
[12:15:54 CEST] <ubitux> N samples in, N/2+1 duo samples out, so 2 samples to save somewhere with inplace
[12:16:00 CEST] <cone-803> ffmpeg 03Luca Barbato 07master:fe026ba96079: drawtext: Drop stray guards
[12:16:01 CEST] <cone-803> ffmpeg 03Hendrik Leppkes 07master:4eded225ade3: Merge commit 'fe026ba960790a004adfcff33f44f96b05538e5c'
[12:18:58 CEST] <cone-803> ffmpeg 03Luca Barbato 07master:98c9ade9853a: drawtext: Move the strftime expansion in a separate function
[12:18:58 CEST] <cone-803> ffmpeg 03Hendrik Leppkes 07master:7e2717ba3c64: Merge commit '98c9ade9853a9c413534ef243174d65f3f7506fa'
[12:19:16 CEST] <cone-803> ffmpeg 03Shiz 07master:b197f7832961: configure: Silence error messages when probing compiler
[12:19:17 CEST] <cone-803> ffmpeg 03Hendrik Leppkes 07master:45d9d16863de: Merge commit 'b197f78329615893201c0e241d00b71b7c749dbb'
[12:21:08 CEST] <nevcairiel> a whole bunch of merges of nothing
[12:22:03 CEST] <wm4> heh
[12:22:04 CEST] <wm4> nice
[12:22:41 CEST] <nevcairiel> the two drawtext things just dont exist in ffmpeg anymore like this, and the configure change was applied independently, so yeah
[12:22:41 CEST] <nevcairiel> :D
[12:23:23 CEST] <nevcairiel> but now i understand why every commit has to be merged, otherwise the script wont knoe which commits still need merging
[12:41:32 CEST] <wbs> well, put another way also, if you do a git merge but not for all commits, all the preceding commits would still be included and appear in the history, not just the one you merged
[12:41:53 CEST] <wbs> but doing it one commit at a time gives you better control and less risk of screwing up, and better bisectability
[12:46:03 CEST] <nevcairiel> oh yeah skipping commits probably wouldnt work anyway, right
[12:46:38 CEST] <wbs> exactly; the way you do it is pretty much equivalent to doing a cherrypick of all commits, one at a time, though, but then you'd be able to skip commits
[12:46:57 CEST] <wbs> but as a merge, git history knows what commits aren't part of what you already have and all such
[12:47:02 CEST] <nevcairiel> merging can probably track changes better
[12:47:12 CEST] <wbs> possibly
[12:47:19 CEST] <nevcairiel> doing weird octopus merge strategies etc
[12:49:19 CEST] <iive> git is written in python, isn't it?
[12:49:26 CEST] <nevcairiel> perl
[12:49:31 CEST] <iive> oh...
[12:49:32 CEST] <nevcairiel> although some parts are C by now, i think
[12:50:26 CEST] <wbs> no, the core is all C
[12:50:37 CEST] <wbs> only very highlevel/external things are perl and some other things, and shellscript
[12:50:41 CEST] <wbs> but the core sure is very much C
[12:50:42 CEST] <wbs> because linus
[12:51:08 CEST] <wbs> (wanting to squeeze all the performance out of all trivial operations that he does millions of times per day)
[12:52:44 CEST] <nevcairiel> somehow i thought more parts were perl
[12:52:50 CEST] <nevcairiel> was it always C from the start?
[12:53:35 CEST] <wbs> yes, C and shell script
[12:53:41 CEST] <wbs> with some shell scripts parts being migrated to C
[12:53:51 CEST] <wbs> perl is used as well but not for anything core
[12:54:16 CEST] <iive> oh, this explains it then.
[12:54:17 CEST] <wbs> things like rebase -i might have been shellscript/perl
[12:57:25 CEST] <wm4> it's all a bit scary
[12:57:34 CEST] <wm4> gitk is also a single huge TCL file
[12:58:43 CEST] <iive> is that for gui?
[12:58:50 CEST] <wm4> yeah
[15:04:18 CEST] <durandal_170> ubitux: I use similar code as in showspectrum so I don't get it where is bug
[15:07:16 CEST] <ubitux> durandal_170: i see no freq glitches in showspectrum for that same sample
[15:07:45 CEST] <ubitux> ./ffplay -f lavfi "amovie=$HOME/samples/pachelbel.mp4,asplit=2[out1],showspectrum=mode=separate:color=intensity:slide=1:scale=cbrt[out0]"
[15:07:57 CEST] <ubitux> top of the graph are pretty fine
[15:15:51 CEST] <ubitux> what's the point of incrementing yourself the position of writing if you are using strlcatf?
[15:15:59 CEST] <ubitux> (re: 4fee11ab05fc8569ef35c0ce86a60375c903eefb)
[15:16:04 CEST] <j-b> a1m
[15:16:40 CEST] <ubitux> +i*5 and -i*5 looks redundant
[15:16:50 CEST] <ubitux> or i'm missing something?
[15:20:27 CEST] <cone-803> ffmpeg 03Ronald S. Bultje 07master:22b30f925d0d: vf_psnr: add psnr_avg to stats file.
[15:55:58 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:500bfbe27ae2: avcodec/hapenc: Remove use of deprecated ff_alloc_packet()
[15:55:59 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:4ab1f33daf48: avcodec/avcodec: Replace AV_CODEC_FLAG* values by 1 << C style for consistency
[15:56:00 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:e740659a5d37: avcodec/avcodec: Define CODEC_CAP_* based on AV_CODEC_CAP_*
[16:21:10 CEST] <ubitux> does anyone know in what potential situation(s) we end up with more than one nal unit in a h264 stream?
[16:21:24 CEST] <ubitux> per packet*
[16:22:25 CEST] <cone-803> ffmpeg 03Anton Mitrofanov 07master:8db0f71b49a3: x86inc: warn if XOP integer FMA instruction emulation is impossible
[16:27:30 CEST] <kierank> ubitux: ?
[16:27:36 CEST] <kierank> multiple slices?
[16:28:11 CEST] <ubitux> i'm going to ask very dumb question, bear with me; does it happen only with interlacing?
[16:29:01 CEST] <ubitux> i was wondering if with threading it was going to make a nal per thread or something, but apparently not
[16:30:52 CEST] <kierank> no it can happen for other reasons
[16:31:01 CEST] <kierank> interlacing (field mode PAFF) is one reason
[16:32:40 CEST] <ubitux> do you see another reason?
[16:33:05 CEST] <ubitux> and the other way around, can you have 1 nal per packet with interlacing?
[16:33:48 CEST] <kierank> ubitux: yes multiple slices in a frame
[16:33:54 CEST] <kierank> you can have one nal per packet with MBAFF, yes
[16:34:58 CEST] <philipl> Every combination is possible! It's so much fun!
[16:35:42 CEST] <nevcairiel> note that are also extra NALs like SPS, PPS, AUD, SEI which also occur in packets
[16:35:46 CEST] <nevcairiel> not only slices
[16:36:00 CEST] <kierank> that too
[16:36:12 CEST] <kierank> I was trying to keep it simple...
[16:36:14 CEST] <ubitux> within ffmpeg context they end up in extradata, no?
[16:36:45 CEST] <nevcairiel> SPS and PPS get copied to extradata, but in a AnnexB stream they are supposed to be repeated regularly
[16:37:02 CEST] <nevcairiel> so cutting is possible
[16:38:55 CEST] <ubitux> assuming video data, larger segmentation such as with more than 2 nal per packet happens?
[16:39:09 CEST] <nevcairiel> Blu-rays have 4 slices
[16:39:14 CEST] <nevcairiel> so 4 nals per frame
[16:39:15 CEST] <ubitux> (video data i mean ignoring the stream meta mentioned above)
[16:39:26 CEST] <ubitux> nevcairiel: what's the purpose of this slicing?
[16:39:37 CEST] <nevcairiel> slice threading possibility, i guess
[16:39:51 CEST] <ubitux> ok
[16:40:03 CEST] <nevcairiel> but the spec asks for 4 slices on 1080p video
[16:40:26 CEST] <ubitux> the bluray specs you mean?
[16:40:30 CEST] <nevcairiel> yes
[16:40:45 CEST] <ubitux> ok, thanks, makes sense
[16:40:54 CEST] <kierank> ubitux: error resilience too
[16:40:59 CEST] <kierank> so that errors don't propagate along slices
[16:41:14 CEST] <ubitux> ok
[16:41:34 CEST] <ubitux> the overhead in size of using multiple slices is not too high?
[16:41:44 CEST] <kierank> not in a large frame size
[16:42:26 CEST] <ubitux> is it possible to cut one slice in multiple nal?
[16:42:33 CEST] <ubitux> i mean, can nal segmentation be more arbitrary?
[16:43:49 CEST] <ubitux> sorry, maybe i should read the specs by myself instead
[16:49:16 CEST] <kierank> I think one slice has to go in one NAL
[16:49:55 CEST] <ubitux> ok, thank you
[16:53:04 CEST] <philipl> This is what made crystalhd so 'fun' to work with. Decoder consumed the entire bitstream without requiring any parsing on the application side, but then you have no idea if you'll get 1:1, 2:1 or 1:2 output pictures vs input packets
[16:53:51 CEST] <kierank> that's arguably the right way to do it
[16:54:23 CEST] <kierank> there's tons of weird field weaving stuff in ffh264
[16:54:24 CEST] <nevcairiel> generally its not a big problem, just that our 1:1 avcodec decode API just doesnt handle it
[16:54:26 CEST] <kierank> which is fine
[16:54:30 CEST] <kierank> yeah
[16:56:58 CEST] <nevcairiel> for future extensibility, moving towards a n:m API might be mandatory, but such a big api change will take years
[16:57:14 CEST] <philipl> yeah. That's what made it a real struggle.
[16:57:35 CEST] <nevcairiel> even existing decoders sometimes do extra buffering due to that API design
[16:57:53 CEST] <nevcairiel> and doing interlaced encoding with x265 is practically impossible with the old api
[16:58:18 CEST] <philipl> yeah.
[16:58:24 CEST] <nevcairiel> ... because the absence of interlaced coding tools in h265 has actually made it more annoying, not less :(
[16:58:40 CEST] <philipl> Aren't we supposed to be in the post-interlaced era at this point?
[16:58:41 CEST] <ubitux> hey i have other questions for h264; maybe you can redirect me to the appropriate part of the specs though; i'm trying to understand the difference regarding data reuse between a full intra frame and a ref frame (that can be a P frame apparently)
[16:58:55 CEST] <nevcairiel> even B can be ref
[16:59:03 CEST] <nevcairiel> h264 is flexible like that
[16:59:05 CEST] <kierank> ubitux: data reuse?
[17:02:06 CEST] <ubitux> kierank: yeah, like i can skip any frame non ref, it won't cause a decoding problem, but if i skip one, it's causing trouble somehow
[17:02:23 CEST] <BBB> ref frames depend on each other
[17:02:24 CEST] <kierank> there are flags in the NAL which signal whether a frame is skippable
[17:02:36 CEST] <BBB> thats what IDR means
[17:02:37 CEST] <kierank> iirc
[17:02:39 CEST] <BBB> independently decodeable ref
[17:03:19 CEST] <kierank> isn't it instantaneous decoder refresh
[17:03:38 CEST] <BBB> something like that yes
[17:04:08 CEST] <BBB> ubitux: so any ref depends (indirectly) on _all_ previous refs, not just the last ref
[17:04:23 CEST] <ubitux> so you can have like 7 successive frames not depending on each other but only on the ref one, which could not be an intra one?
[17:04:38 CEST] <nevcairiel> its unlikely, but yes
[17:04:50 CEST] <ubitux> in which case, what is re-used from this ref frame? everything, just like intra? 
[17:05:13 CEST] <nevcairiel> there is no difference, they depend on the reconstructed frame
[17:05:23 CEST] <ubitux> ok
[17:05:55 CEST] <nevcairiel> so if your ref is broken because it was missing refs, then every following frame will inhereit the problem
[17:07:32 CEST] <nevcairiel> are you trying to solve your 240 fps problem by skipping more frames now :d
[17:08:50 CEST] <philipl> Are these 240fps files encoded just using a special GOP or do they use SVC?
[17:09:11 CEST] <nevcairiel> ordinary h264 fles
[17:09:23 CEST] <ubitux> nevcairiel: well, i'm just trying to have more understanding of h264 because i'm probably going to have to write that async code out of ffmpeg
[17:09:55 CEST] <ubitux> which is a shame but i need to figure out how all of this work without the current hindrance of the limitation of the sync api
[17:10:04 CEST] <ubitux> before i can try something smart in ffmpeg
[17:10:12 CEST] <nevcairiel> doesnt iOS come with a decoder you could call
[17:10:51 CEST] <ubitux> well, i need vtb api
[17:11:03 CEST] <ubitux> the format layering api is too limited for my needs
[17:11:39 CEST] <ubitux> avformat is much better; at least i can seek properly
[17:13:04 CEST] <ubitux> anyway, i was really happy to be able to use everything in ffmpeg, but unfortunately, it's not fast enough
[17:13:24 CEST] <ubitux> so i'll need to mess with the packets themselves and the apple api for now
[17:17:53 CEST] <ubitux> btw, why is qp table not exported with h264 but in the other mpeg like codecs it is?
[17:24:42 CEST] <Zeranoe> In regards to Michael's resignation email, is there more information about "But even now as the last distributions are preparing to remove Libav".
[17:27:23 CEST] <ubitux> Zeranoe: gentoo & debian (+derivatives) were using libav as default provider for the libs*; it changed recently
[17:27:47 CEST] <wm4> kierank: I've always wondered, how does the field weaving stuff work?
[17:27:58 CEST] <wm4> does it actually decode to separate fields, and then "weave" them?
[17:28:10 CEST] <ubitux> git grep FF_QSCALE_TYPE_H264 makes me sad; michaelni, any idea?
[17:28:25 CEST] <nevcairiel> wm4: you decode to the same frame and muck with the linesize to put it in the right place, iirc
[17:29:06 CEST] <wm4> oh I see
[17:29:07 CEST] <wm4> scary
[17:29:21 CEST] <wm4> would it have been better if ffmpeg had decided to output fields only?
[17:29:38 CEST] <nevcairiel> considering every user API wouild have to weave then
[17:29:44 CEST] <nevcairiel> nothing accepts field input =p
[17:29:58 CEST] <wm4> but easier for deinterlacer etc. to handle
[17:30:15 CEST] <wm4> and weaved output is ugly as sin
[17:30:33 CEST] <wm4> most video APIs actually allow you to stretch the output
[17:30:42 CEST] <wm4> so doing what bob does these days would have been trivial
[17:30:54 CEST] <Zeranoe> ubitux: Who still uses Libav above FFmpeg?
[17:31:03 CEST] <ubitux> "above"?
[17:31:17 CEST] <Zeranoe> ubitux: default, instead of
[17:31:37 CEST] <Mavrik> Ubuntu LTE
[17:31:40 CEST] <Mavrik> *LTS
[17:31:46 CEST] <Mavrik> Until 16.04 is out
[17:32:14 CEST] <ubitux> Zeranoe: i don't know any, but probably a bunch of debian derivatives
[17:32:17 CEST] <Mavrik> They're one of the largest install bases, pretty much everyone else defaults to ffmpeg
[17:32:29 CEST] <ubitux> Zeranoe: also, it didn't switch in current debian stable
[17:32:37 CEST] <Zeranoe> Since that ML post, has there been any progress in merging the two projects back together
[17:32:55 CEST] <ubitux> no, libav didn't say much since then
[17:33:24 CEST] <ubitux> we're (maybe only me) still waiting for a list of expectations etc
[17:34:03 CEST] <Zeranoe> Is it the desire of most FFmpeg developers to merge back together?
[17:34:35 CEST] <ubitux> Zeranoe: see http://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/176556.html for the thread concerning ffmpeg devs opinions
[17:35:12 CEST] <ubitux> many still didn't answer though
[17:51:00 CEST] <ubitux> michaelni: ok never mind, i'll send a patch to do the export soon
[18:04:54 CEST] <lglinskih> kierank: how can I determine, if codec is floating-point?
[18:06:35 CEST] <kierank> Bitexact flag
[18:06:48 CEST] <kierank> (On my phone now so can't reply in full)
[18:11:48 CEST] <lglinskih> oh, wrong verb, sorry=/ how can I recognize that some codec is floating-point?
[18:25:45 CEST] <wm4> lglinskih: bitexact is still the right answer
[18:26:13 CEST] <wm4> a decoder which uses floats can output floats, but doesn't have to
[18:26:41 CEST] <wm4> so whether the output of a decoder for the same input is the same on all platforms and CPUs depends on the bitexact flag
[18:27:08 CEST] <lglinskih> cool!
[18:28:03 CEST] <nevcairiel> dont think decoders are flagged like that, are they
[18:28:41 CEST] <wm4> right, you can request it, but the codecs don't report it, I guess
[18:28:51 CEST] <wm4> I have no idea
[18:29:16 CEST] <wm4> some codecs are flagged as lossless, but it's not the same of course
[18:31:29 CEST] <lglinskih> but should all codecs act like bitexact if this flag is set?
[18:32:09 CEST] <wm4> probably not, some codecs likely miss support, but I don't know
[18:39:28 CEST] <lglinskih> for what situations should I set the value of idct_algo?
[18:39:59 CEST] <lglinskih> can it helps me to get fixed output on different platforms for more codecs?
[18:45:44 CEST] <kierank> iirc it should be posible to set it to an integer idct
[18:58:11 CEST] <lglinskih> sooooooooo...I don't know what to do) now I can compare decoder's output with small deviation, but don't know for what codecs I should test it.
[18:59:36 CEST] <lglinskih> and it looks like comparing crcs is more useful as a test
[19:01:05 CEST] <lglinskih> so should I add fate-tests using api-decode-test with bitexact param for...almost all codecs?
[19:01:51 CEST] <kierank> for AV_CODEC_FLAG_BITEXACT you can use crc
[19:01:55 CEST] <kierank> for others you need to use deviation
[19:02:29 CEST] <kierank> but yes
[19:02:40 CEST] <kierank> I'm a bit confused too
[19:03:25 CEST] <lglinskih> =)
[19:03:46 CEST] <kierank> give me 5 mins and i'll see how fate does bitexactness
[19:03:50 CEST] <kierank> might well just be hardcoded
[19:04:09 CEST] <lglinskih> )
[19:05:23 CEST] <philipl> Are there any h.264 FMO/ASO samples around? I didn't see anything obvious in the conformance sample set we have
[19:06:03 CEST] <nevcairiel> dont think i have ever seen FMO in action
[19:06:18 CEST] <kierank> i've seen one in the real-world
[19:06:24 CEST] <kierank> but it's a baseline only feature so meh
[19:07:03 CEST] <philipl> I wanted to see if the new nvidia drivers really handle it. I assume they do because they made such a big deal about only claiming baseline support if they did
[19:07:18 CEST] <nevcairiel> does avcodec even do it
[19:08:37 CEST] <philipl> Hmm. There was a thread about it in 2010.
[19:08:56 CEST] <kierank> most people use constrained baseline
[19:08:59 CEST] <philipl> Indeed.
[19:09:01 CEST] <kierank> which doesn't have all those weird features
[19:09:04 CEST] <kierank> ah ok
[19:09:06 CEST] <philipl> This is pure curiosity.
[19:09:10 CEST] <kierank> they actually mean baseline baseline
[19:09:12 CEST] <kierank> wow
[19:09:24 CEST] <philipl> Yeah.
[19:20:25 CEST] <durandal_170> there are so many vamp visualizations plugins
[19:27:10 CEST] <kierank> lglinskih: I think they're just hardcoded so you could just reuse the fate tests but decode them using the api
[19:29:36 CEST] <wm4> maybe we could add new API for this?
[19:31:40 CEST] <lglinskih> kierank: you mean all tests in fate that uses framecrc, right? 
[19:32:00 CEST] <kierank> I mean fate tests that are not bitexact
[19:32:05 CEST] <kierank> I thought perhaps fate could query the codec
[19:32:21 CEST] <kierank> but it just has the error hardcoded in the test
[19:53:08 CEST] <wm4> why are the videotoolbox/vda decoders some freaky mixture of hwaccel and full bitstream deocders? I don't quite get it
[20:56:12 CEST] <wm4> ignore my lavc patch on  the ML
[20:56:35 CEST] <BBB> does anyone know why https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-trac/ Archives link refers to avcodec.org?
[21:11:21 CEST] <cone-803> ffmpeg 03Marton Balint 07master:b1f78632c681: ffplay: do not block audio thread on WIN32
[21:13:41 CEST] <Compn> BBB : humm, i think for like a day or two during the 2011 server move we had avcodec.org registered in case we didnt have a domain...
[21:14:00 CEST] <Compn> so its possible that was used in the config of the ffmpeg-trac mailing list
[21:14:13 CEST] <Compn> probably ask one of the ml admins or root to fix that
[21:14:45 CEST] <Compn> avcodec.org still directs to ffmpeg.org
[22:00:41 CEST] <wm4> should I push that matroskaenc patch? since I apparently reviewed it
[22:03:19 CEST] <jamrial> yeah
[22:37:11 CEST] <cone-803> ffmpeg 03Sasi Inguva 07master:31852540d4fb: libavformat/matroska: Write stream durations in metadata, in the format of mkvmerge.
[23:04:45 CEST] <rtogni> BBB, Compn list url fixed
[23:04:52 CEST] <BBB> ty very much
[23:17:55 CEST] <cone-803> ffmpeg 03hSÇ 07master:71575d98f5af: avcodec: loongson optimized h264pred with mmi v2
[23:23:25 CEST] <cone-803> ffmpeg 03Henrik Gramner 07master:5e8e121fccc2: checkasm: Remove unnecessary include
[00:00:00 CEST] --- Thu Aug  6 2015