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

[burek]

[01:12:56 CET] <jamrial> fun, i started getting spam in the form of paypal invoces for the amount of $0.00
[01:13:14 CET] <jamrial> clever way to circumvent gmail's spam detector
[01:13:17 CET] <nevcairiel> i just got one of those as well
[01:13:23 CET] <nevcairiel> second in two weeks
[01:13:29 CET] <rcombs> I've been getting some weird and different types of spam today
[01:13:45 CET] <atomnuker> yeah, just got one too
[01:13:55 CET] <rcombs> apparently people have been signing me up for accounts places, and I've been getting confirmation emails
[01:14:11 CET] <rcombs> no paypal account here, though
[01:14:16 CET] <rcombs> so I miss out on that fun
[01:15:11 CET] <rcombs> some idiot's prediction for 2016: "Slack will become so pervasive inside of enterprises that spam will become a problem and third party Slack spam filters will emerge."
[01:15:23 CET] <atomnuker> Its probably the MPEG-LA wanting some cash
[01:15:32 CET] <jamrial> you don't need a paypal account to get invoces
[01:16:05 CET] <rcombs> oh, guess I might have to mark PayPal as spam wholesale if they start showing up then
[02:21:26 CET] <Compn> rcombs : i got about a dozen "confirm your account" emails, even at playstation network hah
[02:21:38 CET] <rcombs> guess it's not just me then
[02:21:53 CET] <Compn> and this is from an email i am not registered on any mailing lists
[03:19:11 CET] <atomnuker> BBB: had time to take a quick look at my decoder yet?
[03:19:16 CET] <BBB> no :(
[03:19:25 CET] <BBB> I wanted to do it today but didnt find time :(
[03:19:51 CET] <BBB> like I said in original reply, its o to push w/o review
[03:19:55 CET] <BBB> but Illr eview later anyway :)
[03:22:12 CET] <atomnuker> well, fixed quite a few things
[03:23:06 CET] <atomnuker> I'll send a final patch in a few mins (if no objections I'll push)
[03:32:30 CET] <jamrial> atomnuker: so it currently can decode samples created with libdaalaenc git HEAD, and the idea is to update it as the format develops?
[03:36:03 CET] <atomnuker> yep, that's pretty much it
[03:36:35 CET] <atomnuker> (patches sent to this decoder will be sent upstream with the author's permission)
[03:37:27 CET] <BtbN> Maybe wait until after tha upcoming release, but I'm not sure if that matters at all for an experimental decoder.
[03:38:32 CET] <atomnuker> it's probably not going to be included in the release (unless the release is a raw snapshot of git master)
[03:38:52 CET] <BtbN> Well, it is?
[03:39:08 CET] <BtbN> I don't think 3.0/2.9 was branched yet
[03:39:44 CET] <atomnuker> okay then
[03:42:11 CET] <atomnuker> anyone knows when the branch will be made?
[03:43:13 CET] <BtbN> michaelni usualy does that
[04:09:13 CET] <cone-228> ffmpeg 03Ganesh Ajjanagadde 07master:a956840cbcf8: ffmpeg: check return value of avio_closep for progress report
[04:09:13 CET] <cone-228> ffmpeg 03Ganesh Ajjanagadde 07master:fc703f53cf3b: lavfi/af_compensationdelay: replace pow(x,0.5) by sqrt(x)
[04:55:53 CET] <philipl> BtbN: so how effective does the intel hybrid vp9 seem to be? I've got skylake hardware arriving in the next week so I can finally poke at it.
[05:04:42 CET] <jamrial> seems to be good for 1080p content only last time he tested it. anything above that and it lags/crashes
[05:06:07 CET] <jamrial> you'll however have no trouble with ffmpeg software decoder and 4k vp9 with that cpu
[05:18:53 CET] <philipl> Yeah, I expect so.
[05:19:24 CET] <philipl> I see that Intel have pushed code to their driver that confirms broxton will have full hardware vp9 decode.
[05:19:46 CET] <philipl> I'm half tempted to change my mind and return the nuc when I get it and hold out another year.
[05:20:48 CET] <J_Darnley> :)
[05:21:00 CET] <J_Darnley> Then there will be some other feature you want to waitfor.
[05:21:37 CET] <philipl> Yeah. It's futile. My mediacentre is an ivy bridge nuc right now, so it's had a good run.
[10:03:07 CET] <ubitux> michaelni: i'll deal with the cc patches
[10:03:48 CET] <ubitux> tmm1: 2 general comments; can you change "libavcodec" to "lavc" in the patch message, and can you squash all the whitespaces changes together?
[10:04:06 CET] <ubitux> also, if you have a public git repo, it will be simpler for me to merge
[10:15:03 CET] <mateo`> am I blind or does the NDK MediaCodec API *not* provide a way for the user to know the {dec,enc}oder name (so we can deal with broken decoders/encoders that lie about the format they output) ?
[10:18:30 CET] <durandal_1707> ubitux: avcodec it is, not lavc
[10:19:17 CET] <ubitux> durandal_1707: well i though we decided lavc/lavf/lavfi/lavu
[10:19:39 CET] <durandal_1707> nope, let's vote
[10:20:16 CET] <ubitux> as you wish... mind to send the [DECISION] mail?
[10:22:22 CET] <durandal_1707> [RULES]
[10:51:56 CET] <wbs> mateo`: apparently not; originally there wasn't such a method in java either, but I contributed it and it got included in API level 18
[10:53:33 CET] <wbs> mateo`: if you want to do codec blacklisting/whitelisting, you probably need to use MediaCodecList anyway, and that's not in the NDK afaik
[10:54:15 CET] <wbs> mateo`: note that originally (in android 4.1), using createDecoderByType was pretty dangerous, since it crashed the whole process if you tried to create a codec that didn't exist (so you'd have to check with MediaCodecList first to be safe anyway)
[10:54:48 CET] <wbs> mateo`: (which still didn't stop some manufacturers from e.g. listing that they had a vp8 decoder in MediaCodecList, which actually didn't exist, so trying to create that would kill your process as well)
[11:01:30 CET] <mateo`> so even if we go with the C API we will still need some jni to handle the different broken cases ...
[11:01:52 CET] <mateo`> suddently it feels pointless to use the C API ...
[11:02:33 CET] <wm4> at least we get the satisfaction of knowing that Google is losing money due to having to pay Oracle for the java crap
[11:08:37 CET] <mateo`> really, I wanted to avoid as much as possible of this bullshit ... but it's even possible even with android >= 21. One of the phone i've tested the code against reported a color format of YCbCr (422) and is ... actually ~nv12
[11:11:10 CET] <mateo`> wbs: also, the NDK MediaCodec API does not let you retreive the codec index needed by MediaCodecList :(
[11:13:29 CET] <wm4> what, they somehow set the wrong format on returned frames?
[11:15:37 CET] <mateo`> yes
[11:16:40 CET] <wm4> that sounds like the sort of bugs you need blacklists with vendors and driver versions to work around...
[11:17:08 CET] <wbs> mateo`: indeed, so createDecoderByType is essentially useless - you need to instead look through the list and manually pick one
[11:17:23 CET] <wbs> mateo`: as for incorrect pixel format - that sounds very strange
[11:17:29 CET] <wbs> mateo`: there used to be lots of those before 4.3
[11:17:52 CET] <wbs> mateo`: but since 4.3, there's a CTS test that is mandatory for a device to be shipped, which enforces them to return sensible values
[11:18:11 CET] <wbs> mateo`: there are a bunch of loopholes in it though (e.g. it's ok for a decoder to return an opaque format, like qualcomm does)
[11:18:53 CET] <wbs> see https://android.googlesource.com/platform/cts/+/master/tests/tests/media/src/android/media/cts/EncodeDecodeTest.java#1106
[11:19:12 CET] <durandal_1707> michaelni: can you look at patch that fixes leaks on failure for avfilter?
[11:19:16 CET] <wbs> ah, so if (!isRecognizedFormat(colorFormat)) -> instant pass in the test
[11:19:41 CET] <mateo`> I'm aware of those tests
[11:20:01 CET] <wbs> yes - I just wanted to get clarity in why devices can ship with wrong chroma despite them
[11:20:02 CET] <mateo`> but i'm pretty sure i'm facing this one ... http://lists.freedesktop.org/archives/gstreamer-commits/2013-June/072118.html
[11:20:33 CET] <wbs> (but since the test doesn't recognize COLOR_FormatYCbYCr it can pass just fine)
[11:24:29 CET] <durandal_1707> does this foo guy have real name?
[11:24:44 CET] <nevcairiel> everyone does
[13:33:21 CET] <ubitux> wm4: would you like the idea of av_opt_set(avctx, "sub_ass_format", "no_timing", 0)?
[13:33:28 CET] <ubitux> i'm pretty much done
[13:33:49 CET] <ubitux> (the option would become the default in the future)
[13:34:59 CET] <kierank> wm4: what is the problem with closed caption displaying?
[13:35:05 CET] Action: kierank doesn't understand the issue
[13:35:36 CET] <wm4> kierank: supposed you have a line of text at timestamp A, and another one at timestamp B (and it doesn't change until then)
[13:35:48 CET] <wm4> then the current CC decoder will buffer the event for timestamp A until timestamp B
[13:36:04 CET] <kierank> why
[13:36:17 CET] <wm4> because ASS is a timed format
[13:36:31 CET] <wm4> and the decoder tries to output a single ASS event for each line of text
[13:36:44 CET] <kierank> ass doesn't have the concept of display until something else happens?
[13:36:53 CET] <JEEB> nope
[13:36:56 CET] <JEEB> it's multi-layered
[13:36:58 CET] <wm4> no
[13:37:04 CET] Action: kierank cries
[13:37:05 CET] <JEEB> and you can have multiple entities on the same layer even
[13:37:21 CET] <JEEB> well, it just lives to its name :P
[13:37:24 CET] <ubitux> with my current patch it won't be much of an issue anymore
[13:37:27 CET] <kierank> ok looks like I'll have to write my own cc decoder or steal VLCs perhaps
[14:00:17 CET] <wm4> kierank: well, it's not like it can't be solved, but using ASS as markup bites us a bit here
[14:00:19 CET] <J_Darnley> What a mess of a ticket.
[14:00:23 CET] <wm4> on the other hand, all alternatives were even worse
[14:00:47 CET] <wm4> (generic supersets, markup ASTs etc.)
[14:01:38 CET] <kierank> for display thankfully I don't think anyone will notice if they are not frame accurate
[14:02:20 CET] <ubitux> https://github.com/ubitux/FFmpeg/compare/ass-2016
[14:02:31 CET] <ubitux> this should be passing fate-subtitles pretty soon
[14:02:39 CET] <ubitux> then i'll add an option and i'm done
[14:02:49 CET] <ubitux> no more timing shit in the decoded form
[14:02:59 CET] <kierank> I am nervous about incorporating ass into my stuff, feels like i could open a world of pain
[14:03:12 CET] <ubitux> and as a side effect, should fix all the timing rounding crap
[14:08:55 CET] <wm4> ubitux: heh, that rounding was a big problem (but is effectively worked around now)
[14:10:32 CET] <ubitux> anyway, after this, you can call subtitle decode with every sub packet
[14:10:41 CET] <ubitux> and feed sub->rects[N]->ass to libass directly
[14:11:26 CET] <ubitux> if the decoder is ass, whole dialog is just copied, for other decoders ass markup is computed as usual and the readorder is simply incremented in the context (and reset to 0 in cases of flush) 
[14:11:58 CET] <wm4> there's just one problem: I don't want to clear the libass event list when seeking
[14:12:09 CET] <wm4> it would also mean to reconvert all subtitles when seeking
[14:12:22 CET] <wm4> (but I'm not sure myself what's the best way to handle this)
[14:12:28 CET] <ubitux> it's reset to 0 only for decoders where the read order doesn't matter
[14:13:03 CET] <ubitux> maybe a flag would be present
[14:14:21 CET] <ubitux> wm4: why don't you want to clear the list btw?
[14:16:42 CET] <wm4> it has 2 advantages: avoiding to reconvert, and seeking or adjusting subtitle delay by event
[14:17:04 CET] <wm4> the latter just requires the player to know at which times subtitle events happen
[14:17:19 CET] <ubitux> since convert is done incrementally,why does it matter?
[14:18:59 CET] <wm4> that would require some logic to prevent packet ahead reading (for external subtitles)
[14:20:04 CET] <wm4> I wonder if I should just make some sort of wrapper that makes a srt demuxer behave like a srt demuxer to work around these issues
[14:20:19 CET] Action: ubitux confused
[14:20:21 CET] <wm4> that makes a srt demuxer behave like an ass demuxer
[14:20:45 CET] <ubitux> the srt and ass demuxer behave the same afaik
[14:21:06 CET] <wm4> that'd be annoying for muxed srt subs though (the converter would have to be at two levels)
[14:21:10 CET] <ubitux> the whole file is read, and events/packets put in a seekable internal queue
[14:21:34 CET] <wm4> I know
[14:23:30 CET] <ubitux> i still don't understand the problem
[14:24:02 CET] <ubitux> anyway, this patchset should clearup a bit the garbage pile
[14:24:14 CET] <ubitux> it will be a saner base
[14:24:48 CET] <wm4> ubitux: my own code just feeds packets to libass (converts them before that if the source is e.g. srt)
[14:25:05 CET] <wm4> then, some features use ass_step_sub()
[14:25:25 CET] <wm4> which finds the next/previous subtitle at a given timestamp (this is used for subtitle seek, or adjusting subtitle delay)
[14:25:50 CET] <ubitux> subtitle seek = seek playback to next sub event?
[14:25:58 CET] <wm4> yes
[14:26:10 CET] <wm4> for subtitles interleaved with video, this works only with already seen subs
[14:26:18 CET] <wm4> a bit annoying, but mostly unavoidable
[14:26:41 CET] <wm4> for plain subtitle files, it means all packets have to be added to libass on init or so
[14:30:20 CET] <ubitux> right, so the only thing that will change here is simply that instead of feeding packets to libass or convert them (and then remove the dialogue crap if you used lavc), you will just always decode the packet (in case of ass it's a simple copy of the payload), and feed sub->rects[N]->ass to libass
[14:30:41 CET] <ubitux> rest should remain unchanged
[14:32:19 CET] <wm4> ubitux: this is what I do: https://github.com/mpv-player/mpv/blob/master/sub/sd_ass.c#L237
[14:32:38 CET] <wm4> lavc_conv_decode() is merely a wrapper around avcodec_decode_subtitle2()
[14:32:49 CET] <ubitux> ok
[14:33:24 CET] <wm4> check_packet_seen() is some sort of replacement for the ReadOrder check
[14:33:48 CET] <wm4> it uses the file byte position as unique ID, which happens to work for all demuxers
[14:33:55 CET] <ubitux> mmh
[14:34:13 CET] <ubitux> yeah, until it's a >4G file
[14:34:40 CET] <wm4> it uses a int64_t
[14:34:45 CET] <ubitux> i guess you don't forward it to libass?
[14:35:27 CET] <wm4> no, because this is the code path for the "old" packet format, which doesn't have a readorder field at all
[14:35:38 CET] <ubitux> ok
[14:36:10 CET] <ubitux> i thought many demuxer were not setting the position
[14:36:39 CET] <wm4> so check_packet_seen() is my replacement for ReadOrder in the srt case, which means I can handle srt/ass and standalone/muxed subtitles fully equivalent
[14:47:08 CET] <cone-366> ffmpeg 03Mats Peterson 07master:6a975cb07f40: lavf/matroskadec: correct codec_tag for "SMI" SVQ3 files
[14:57:08 CET] <wm4> I wonder why the pad filter has to do such elaborate obscure things
[14:57:15 CET] <wm4> which, guess what, break
[14:58:25 CET] <durandal_1707> wm4: what breaks?
[15:02:17 CET] <wm4> I don't know what the ticket above is about, but there was also a patch on the ML to fix vf_pad in certain cases
[15:05:11 CET] <wm4> actually maybe this is unrelated to what I was thinking about, so never mind
[15:54:09 CET] <ubitux> wth is he talking about
[15:54:40 CET] <Daemon404> i have no idea
[15:54:47 CET] <ubitux> we should also stop allowing markup in the trac
[15:54:59 CET] <ubitux> it's useful, but these dumbass make it unreadable
[15:55:00 CET] <Daemon404> i think having a code tag is good
[15:55:11 CET] <Daemon404> i hate reading non-monospaced console output
[15:55:23 CET] <ubitux> well it could be all monospaced
[15:56:18 CET] <ubitux> seriously i read its 3 first sentence several times, i don't have a clue what he's talking about
[15:56:22 CET] <prelude2004c2> hey everyone good day.. having an issue with playback... ( see http://pastebin.com/XAVQL9bz ) ... basically when i record something from the live stream and i try to playback it always plays the end of the stream and not from the beginning. I am told it is because the start time of the recording has  negative value and the system can't play something with a negative value.. can anyone point me in the right direction
[15:56:22 CET] <ubitux> his*
[15:56:47 CET] <ubitux> prelude2004c2: #ffmpeg
[15:57:03 CET] <prelude2004c2> ehh yes.. well i missed the -devel :(
[15:57:04 CET] <prelude2004c2> sorry
[15:57:44 CET] <ubitux> no worry
[15:57:57 CET] <prelude2004c2> let's hope someone is chatty there :P haha
[15:58:56 CET] <wm4> Daemon404: just kill stagefright already
[15:59:17 CET] <Daemon404> ill wait af ew hrs
[15:59:23 CET] <Daemon404> i dont wnat revert wars
[15:59:26 CET] <Daemon404> or butthurt yelling
[15:59:43 CET] <Daemon404> for once, im tyring to be diplomatic
[15:59:46 CET] <Daemon404> unlike me, i know.
[16:43:56 CET] <cone-366> ffmpeg 03Andrey Turkin 07master:149b1f7ccafa: avfilter/vf_pad: fix direct padding
[17:25:23 CET] <BBB> Daemon404: what did you do to the real Daemon404 
[17:25:36 CET] <Daemon404> ;)
[17:25:38 CET] <Daemon404> gonna push now
[17:25:43 CET] <BBB> ah there he is
[17:25:45 CET] <BBB> ok
[17:33:39 CET] <wm4> now someone send stagefright wrapper to Libav, so cehoyos gets a heart attack
[17:33:52 CET] <nevcairiel> hahaha
[17:33:53 CET] <wm4> well, after it's pushed
[17:36:38 CET] <Daemon404> just waiting for a dist-upgrade to finish before
[17:37:51 CET] <kierank> wm4: wow that's brilliant
[17:43:48 CET] <cone-366> ffmpeg 03Derek Buitenhuis 07master:72673ad7eae2: avcodec: Remove libstagefright
[17:44:03 CET] <kierank> !!!!!!!!!!!!!!!!!!!!!!!!1
[17:44:04 CET] <atomnuker> SEE THIS SHIT^^
[17:44:06 CET] <atomnuker> SEE IT
[17:44:21 CET] <nevcairiel> i'm surprised there was no big outcry on the ML from someone, carl must not care about android =p
[17:44:40 CET] <Daemon404> nevcairiel, i doubt he sees many tracker thinsg about it
[17:44:45 CET] <Daemon404> since nobody can figured out how to use it.
[17:44:45 CET] <mateo`> woo ooo ~~
[17:45:28 CET] <kierank> ONE SMALL STEP FOR (A) MAN
[17:45:32 CET] <kierank> ONE GIANT LEAP FOR MANKIND
[17:46:32 CET] <atomnuker> next time I hear one of you say shit never gets removed I'm linking this
[17:47:00 CET] Action: atomnuker wonders if wm4 will remove the tons of FUD from the mpv wiki now
[17:47:23 CET] <kierank> it's the first time shit was removed
[17:47:25 CET] <kierank> EVER
[17:47:42 CET] <wm4> lol
[17:47:54 CET] <kierank> <clarkson>IN THE WORLD</clarkson>
[17:48:06 CET] <Daemon404> kierank, mpcodecs was remove
[17:48:07 CET] <Daemon404> d
[17:48:08 CET] <wm4> atomnuker: anyone can edit that wiki
[17:48:08 CET] <nevcairiel> unless someone crazy shows up, we'll replace the dca decoder in a while without duplicating it
[17:48:39 CET] <wm4> but in reality, only 1 unknown account edited it, using the commit message "Enjoying your "No Michael Niedermayer allowed" tree-house, Libav devs?" (was reverted as vandalism)
[17:48:52 CET] <kierank> Daemon404: "removed"
[17:49:55 CET] <atomnuker> wm4: oh yeah, I forgot about that
[17:51:28 CET] <ubitux> kierank: "absorbed"
[17:51:30 CET] <ubitux> ;)
[17:56:41 CET] <ubitux> nevcairiel: the threading in ffmpeg is reworked, you might want to keep the support for platforms with no threading
[17:56:47 CET] <ubitux> ffmpeg cli*
[17:57:13 CET] <Daemon404> what platforms are those anywya
[17:57:44 CET] <ubitux> maybe platforms were a pthread compat implementation exist
[17:57:49 CET] <ubitux> not sure if there are any
[17:57:50 CET] <nevcairiel> ubitux: i probably wouldnt have merged that anyway, it seems like one of those "cba to fix, disable" things
[17:58:17 CET] <Daemon404> it seems to provide a very dubious benefit
[18:00:06 CET] <kierank> Daemon404: yeah but avconv is getting threading
[18:00:09 CET] <kierank> so hurr durr
[18:00:14 CET] <jamrial> kierank: not true. i was able to remove a non pkgconfig configure check once
[18:00:17 CET] <Daemon404> ... for the progress report
[18:00:34 CET] <Daemon404> was it removed or kept as a fallback jamrial 
[18:00:42 CET] <jamrial> removed
[18:00:49 CET] <Daemon404> wow
[18:01:27 CET] <jamrial> carl wanted to keep it as fallback, i said no because it was never in a release to begin with so he can't claim regression
[18:02:13 CET] <Daemon404> ... x264 has never had a release, and always (afaik) had pkg-config
[18:02:13 CET] <Daemon404> so.
[18:02:15 CET] <Daemon404> <_<
[18:02:19 CET] <Daemon404> yet we kept its fallback
[18:02:34 CET] <Daemon404> in fact the minimum supported x264 version has pkg-config.
[18:02:41 CET] <Daemon404> (or did we ever even push pkg-config support?)
[18:03:02 CET] <ubitux> yes, to make sure it's picking the one you don't want to on your system when you messed up your PKG_CONFIG env
[18:03:06 CET] <ubitux> instead of failing properly
[18:03:08 CET] <ubitux> :(
[18:03:14 CET] <Daemon404> that sounds retarded
[18:03:20 CET] <Daemon404> and very very error prone
[18:03:25 CET] <jamrial> i mean ffmpeg release
[18:03:29 CET] <Daemon404> jamrial, o
[18:06:23 CET] <jamrial> if say ffmpeg 2.8 detects a library without pkgconfig and then suddenly 2.9 does it and without fallback, people with broken environments could theoretically have issues
[18:06:36 CET] <jamrial> that's the argument carl used every time we had to keep a fallback in place
[18:06:41 CET] <Daemon404> i dont call that an issue
[18:06:50 CET] <Daemon404> i dont think supporting broken envs should be a goal
[18:06:54 CET] <Daemon404> if anything, breaking it helps them fix it
[18:07:20 CET] <jamrial> it isn't, and we shouldn't, but people bitch on trac and carl wants to close the ticket with something else than "wont fix"
[18:09:38 CET] <jamrial> Daemon404:  you could have added some reviewed-by lines to the commit
[18:10:04 CET] <Daemon404> jamrial, nobody reviewed
[18:10:06 CET] <Daemon404> everybody acked
[18:10:07 CET] <Daemon404> i almost did
[18:10:12 CET] <Daemon404> but that would be like 8 acked-by
[18:10:20 CET] <Daemon404> and thats pretty sill
[18:10:50 CET] <jamrial> it would work as ammunition in case people show up complaining about the removal :p
[18:11:12 CET] <Daemon404> the ML has an archive
[18:11:15 CET] <Daemon404> for this reason
[18:30:31 CET] <jamrial> "[PATCH] avconv: Depend on pthreads directly" they are nuts
[18:54:35 CET] <wm4> jamrial: why
[18:55:24 CET] <jamrial> avconv wouldn't work on windows anymore unless you use one of the many pthreads emulation libraries
[18:55:52 CET] <wm4> like ffmpeg/libav has one?
[18:56:07 CET] <nevcairiel> no, that one specifically is not used
[18:56:11 CET] <nevcairiel> they depend on pthreads directly
[18:56:12 CET] <jamrial> we don't. we have a wrapper for a subset of pthreads
[18:56:26 CET] <wm4> surely that's just an accident
[19:07:32 CET] <prelude2004c2> hey been waiting for help on ffmpeg for 3 hours.. not a single reply in the channel.. can anyone here hep ?
[19:07:34 CET] <prelude2004c2> help*
[19:07:43 CET] <prelude2004c2> probably something very simple
[19:09:27 CET] <prelude2004c2> new udpated code : http://pastebin.com/NTF2pjKC
[19:10:45 CET] <mark4o> prelude2004c2: wrong channel; try #ffmpeg
[19:11:01 CET] <prelude2004c2> i have been :) .. no chat in the channel for 3 hours now
[19:11:03 CET] <prelude2004c2> and counting
[19:11:03 CET] Action: J_Darnley skiggers
[19:11:37 CET] <J_Darnley> What was the problem?
[19:12:41 CET] <J_Darnley> All I see is a load of weird options
[20:32:00 CET] <durandal_1707> anybody wants to add visualizations from lavfi to ffplay
[21:22:37 CET] <prelude2004c2> hi darley
[21:22:46 CET] <prelude2004c2> sorry it took me a while to respond
[21:23:10 CET] <prelude2004c2> the issue is that when i use a PVR option they say the recording start time is a negative value.. i guess it has to do with key frames or whatever and the seeking options
[21:23:18 CET] <prelude2004c2> i have been trying to play with it but nothing i do seems to work :(
[21:28:34 CET] <cone-653> ffmpeg 03Vicente Olivert Riera 07master:6282bdc2bf36: mips: display a warning message when using an unknown CPU
[21:42:46 CET] <ubitux> tmm1: so do you have your cc tree in a public repo?
[22:17:29 CET] <cone-653> ffmpeg 03Michael Niedermayer 07master:23679d82f69c: configure: use warn() for mips unknown cpu warning
[23:19:56 CET] <cone-509> ffmpeg 03Aman Gupta 07master:55ca79f5268f: libavcodec/ccaption_dec: clean up and standardize white space
[23:19:56 CET] <cone-509> ffmpeg 03Aman Gupta 07master:3ec5d8fe0ff1: libavcodec/ccaption_dec: rewrite packet handler as case statement; remove COR3 macro
[23:27:52 CET] <tmm1> ubitux:  i don't but i can push it up
[23:29:48 CET] <tmm1> ubitux: https://github.com/pyrot/ffmpeg/compare/master...upstream-cc-cleanups
[23:29:58 CET] <tmm1> hrm
[23:30:08 CET] <tmm1> that's not public, one sec
[23:31:09 CET] <tmm1> https://github.com/tmm1/FFmpeg/compare/master...upstream-cc-cleanups
[00:00:00 CET] --- Thu Jan  7 2016