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

[burek]

[01:43:21 CEST] <cone-788> ffmpeg 03Andriy Lysnevych 07master:2fe04630e7d9: avcodec/avpacket: Respect payload offset in av_grow_packet
[01:43:22 CEST] <cone-788> ffmpeg 03Mark Thompson 07master:7e0623b70ba7: vaapi: Enable more libva surface formats
[06:32:45 CEST] <prelude2004c> DHE , you around yet 
[06:32:47 CEST] <prelude2004c> ?
[07:03:22 CEST] <cone-114> ffmpeg 03Paul B Mahol 07master:a3c2a9c736dd: avcodec/magicyuv: fix decoding of raw slices
[09:34:17 CEST] <nevcairiel> ubitux: i saw one small error which should not affect fully compliant files, but otherwise nothing obviously wrong
[09:34:22 CEST] <nevcairiel> (left a comment on gh)
[09:58:20 CEST] <ubitux> nevcairiel: thanks, will have a look now
[11:27:36 CEST] <cone-114> ffmpeg 03Muhammad Faiz 07master:1b05521bb729: avfilter/avf_showcqt: full chroma blending on draw_axis_yuv
[11:56:59 CEST] <DHE> <prelude2004c> DHE , you around yet # What do you mean 'yet'? It was ~12:30am when you said that
[12:52:10 CEST] <BtbN> nevcairiel, you happen to know what data format cuvidParseVideoData expects? It's simply doing nothing for me, no error, no output.
[13:06:29 CEST] <nevcairiel> all hardware apis typically want annexb
[13:43:24 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07master:4865252c0817: avformat/udp: Protect write to circular_buffer_error by mutex
[13:49:34 CEST] <ubitux> nevcairiel: i changed it locally to use a local tmp gb copy (in the case scope)
[13:49:54 CEST] <ubitux> (instead of a dubious backup in the h264context)
[13:50:13 CEST] <nevcairiel> the last case specifically re-inited the reader using the still escaped buffer, did you adjust that one as well?
[13:51:32 CEST] <nevcairiel> seems like you did
[13:52:15 CEST] <ubitux> GetBitContext tmp_gb = nal->gb, first one use tmp_gb, then for the second attempt, tmp_gb becomes a new one with the complete NAL and is used that way, and for the 3rd and last attempt, it's the yet untouched original nal->gb
[13:52:34 CEST] <ubitux> does that make sense?
[13:52:38 CEST] <nevcairiel> does it still fail?
[13:52:43 CEST] <nevcairiel> sounds ok
[13:52:51 CEST] <ubitux> yeah i have crashes in some random places
[13:53:04 CEST] <ubitux> seems like long ref are missing or something
[13:53:17 CEST] <ubitux> i have no idea what causes this
[13:55:25 CEST] <xx_pk_xx_> Hello guys. I'm trying to decode DVB subtitles using avcodec_decode_subtitle2 function. Is it possible to save those subtitles as png images? My current code is here: http://pastebin.com/G2aThmvR I'm not even able to get start/end times of the subtitles. Does anyone know what am I doing wrong? I'm sorry if I shouldn't ask this question here
[13:56:13 CEST] <ubitux> it probably belongs to #ffmpeg unless you're talking about updating the ffmpeg code
[13:57:14 CEST] <xx-pk-xx> alright, thank you anyway. Could anyone at least point me to the right direction? 
[14:30:11 CEST] <ubitux> ok found the crash
[14:34:55 CEST] <ubitux> so apparently it's because i'm messing with pps_ref_count in the wrong way
[14:35:50 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_refs.c;hb=HEAD#l809
[14:36:02 CEST] <ubitux> can i have a summary of the purpose of that code?
[14:40:55 CEST] <ubitux> the loop looks meaningless
[14:41:03 CEST] <ubitux> unless i'm missing something obvious
[14:41:19 CEST] <ubitux> michaelni ^
[14:42:36 CEST] <ubitux> and pps_count is write only
[14:42:38 CEST] <ubitux> oO
[14:43:44 CEST] <ubitux> so pps_count can be removed altogether, and  pps_ref_count[0,1] can be set without the loop
[14:43:48 CEST] <ubitux> am i missing something?
[14:46:01 CEST] <michaelni> ubitux, pps_count can be removed the code that used it was removed a year ago i think
[14:46:18 CEST] <michaelni> if so that might be best to do in a seprate commit before the merge
[14:46:18 CEST] <ubitux> the loop as well
[14:46:33 CEST] <ubitux> feel free to update that code before the merge
[14:48:01 CEST] <michaelni> pps_ref_count[] set by the loop is still used or did you mean another loop ?
[14:48:08 CEST] <michaelni> ill remove pps_count
[14:48:21 CEST] <ubitux> well it's always doing the same thing
[14:48:24 CEST] <ubitux> i is not involved
[14:48:39 CEST] <nevcairiel> this is true, how odd
[14:48:58 CEST] <michaelni> thats a bug id guess
[14:49:19 CEST] <ubitux> anyway, it's crashing in the merge in that area because the pps can be NULL, but well, that's my issue :)
[14:49:40 CEST] <michaelni> ill take a look at the [0] vs [i] issue in git master
[14:49:45 CEST] <ubitux> thanks
[14:50:16 CEST] <ubitux> btw, how do you rebase a merge? git rebase --preserve-merges master caused all kind of shit last time i did it
[14:50:25 CEST] <nevcairiel> one doesnt
[14:50:32 CEST] <ubitux> heh
[14:50:33 CEST] <nevcairiel> for some reason git fails at that
[14:50:46 CEST] Action: michaelni avoided rebasing merges
[14:50:51 CEST] <ubitux> i guess i'll do it manually
[14:51:02 CEST] <ubitux> copy all the files somewhere, re-run the merge, restore files :p
[14:51:05 CEST] <nevcairiel> with complex shit like that, the easiest solution is the ghetto approach and save the diff, then re-apply the merge with --preserve-ours and apply the diff ontop
[14:51:14 CEST] <ubitux> exactly :D
[14:51:16 CEST] <ubitux> ok :)
[14:51:20 CEST] <nevcairiel> (better then copying files)
[14:51:35 CEST] <ubitux> u not ghetto nuff
[14:51:41 CEST] <michaelni> one thing to look out for with that is newly added files (which need git add)
[14:52:01 CEST] <ubitux> yeah, i'll be carefull :)
[14:52:08 CEST] <nevcairiel> actually the option is "-s ours", not preserve
[15:03:20 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07master:a8289d2407e0: avcodec/h264_refs: Remove unused pps_count
[15:03:21 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07master:3402871f36f9: avcodec/h264_refs: Fix pps_ref_count with multiple PPS
[15:05:22 CEST] <ubitux> thanks michaelni 
[15:17:24 CEST] <ubitux> yay it seems to work
[15:17:37 CEST] <ubitux> going to do a bunch of tests and will ask for testing
[15:19:20 CEST] <nevcairiel> i can probably do a few more merges over the weekend, unless you're on a roll now and want to continue right away after this beast :)
[15:20:25 CEST] <ubitux> not decided yet
[15:22:26 CEST] <BtbN> nevcairiel, annexb was the one with the 0x00 00 00 01 stuff, right?
[15:22:41 CEST] <nevcairiel> yes
[15:22:47 CEST] <BtbN> So basically I need that bsf
[15:23:06 CEST] <BtbN> But what a strange API, it happily accepts all data, does not throw a single error about it.
[15:29:01 CEST] <nevcairiel> well its probably looking for the annexb start code, any random data could be part of the frame data
[15:29:13 CEST] <ubitux> michaelni: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_sei.c;hb=HEAD#l56 is it on purpose that sps->log2_max_frame_num is check at every iteration? wouldn't it make sense to not enter the loop at all if set?
[15:29:43 CEST] <nevcairiel> ubitux: sps can be changed in the loop
[15:29:58 CEST] <ubitux> oh my bad
[15:32:39 CEST] <BtbN> nevcairiel, yeah, but after several MB of garbage data I would expect some kind of negative feedback.
[15:33:15 CEST] <nevcairiel> i've seen keyframes exceeding hardware buffer sizes because they are too big, which would be >10MB or so
[15:33:22 CEST] <nevcairiel> that reminds me that i wanted to fix that
[15:33:53 CEST] <BtbN> yeah, but some failsafe like "there was not a single startcode in the last 50MB" would be nice
[15:36:52 CEST] <ubitux> ok it's ready for testing michaelni, nevcairiel 
[15:36:56 CEST] <ubitux> it seems to be passing fate
[15:37:11 CEST] <ubitux> michaelni: can you test with the sample from e708424b70bef8641e8a090ec4d9e8c4490db87e ?
[15:41:49 CEST] <ubitux> ah actually, fate doesn't pass fully it seems
[15:43:49 CEST] <mateo`> is there a proper way to test vaapi ?
[15:44:03 CEST] <mateo`> and all hwaccel related to h264 ?
[15:47:24 CEST] <ubitux> "if it builds, it works"
[15:51:39 CEST] <michaelni> mateo`, "ffmpeg -hwaccel" should be able to be used
[15:51:57 CEST] <ubitux> duration seems broken in flv-demux fate test
[15:52:00 CEST] <ubitux> :(
[15:53:00 CEST] <mateo`> michaelni: my current hardware only supports vdpau it seems (I have a radeon r9 m370x)
[15:53:34 CEST] <mateo`> there is no protocol to follow to properly test the hwaccel ? just go through random files and see how it goes ?
[15:56:00 CEST] <ubitux> (ok just a bug in the parser)
[16:01:57 CEST] <jkqxz> FATE is usable, with a bit of hackery.  "make HWACCEL='vaapi -hwaccel_output_format yuv420p -hwaccel_lax_profile_check' fate-h264" passes most of the tests on Intel.  (I really should fix it so it doesn't need the output option.)
[16:02:32 CEST] <michaelni> ubitux, tell me when i shuld refetch to test
[16:02:50 CEST] <ubitux> you can start testing but there is currently a bug in the parser
[16:03:08 CEST] <ubitux> which makes flv-demux output different durations
[16:03:11 CEST] <mateo`> jkqxz: thanks, i'll use that to test the merge
[16:07:46 CEST] <BtbN> Is there some magic flag I can set, so I automatically get that bsf, or do I have to set it up manually?
[16:08:22 CEST] <michaelni> jkqxz, can it be made to work as fate client in fate ? it would be very usefull to have automated hwaccel testing on fate.ffmpeg.org
[16:08:55 CEST] <BtbN> The API to do it manually is marked as deprecated.
[16:16:12 CEST] <nevcairiel> BtbN: then use the new manual api :)
[16:16:43 CEST] <nevcairiel> BtbN: av_bsf_* api
[16:17:01 CEST] <nevcairiel> av_bitstream_filter* is the old one
[16:18:41 CEST] <BtbN> Ah. Looks like only audiotoolboxdec.c is using it so far. So I'll just take it from there.
[16:22:01 CEST] <BtbN> Looks like it's working.
[16:24:33 CEST] <BtbN> It doesn't honor what the header says though, it does not keep calling av_bsf_receive_packet until it returns EOF/EAGAIN
[16:25:21 CEST] <BtbN> Shouldn't matter too much for the mp4toannexb filter
[16:25:22 CEST] <nevcairiel> the annexb thing is 1:1 filter, so it can cheap out
[16:25:38 CEST] <jkqxz> michaelni:  It should be.  Getting that set up is on my to-do list.
[16:25:43 CEST] <BtbN> Well, it's using the aac adts filter, but i guess it works similary
[16:26:10 CEST] <nevcairiel> most filters are 1:1, because thats the only thing the old api allowed
[16:26:30 CEST] <nevcairiel> we have like one m:1 filter, but no 1:m filter
[16:26:53 CEST] <BtbN> Now I just have to queue the output frames, and send them out. And the cuvid h264 decoder should be done.
[16:27:04 CEST] <BtbN> Still amazed that it just works, even though that API is documented as Windows-Only.
[16:31:08 CEST] <BtbN> I don't understand who cleans up the filtered packet though. https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/audiotoolboxdec.c#L508
[16:32:16 CEST] <nevcairiel> BtbN: it seems to be tracked in at->new_in_pkt
[16:32:28 CEST] <nevcairiel> but yes it needs to be freeed eventually
[16:33:35 CEST] <BtbN> Well, I hope it's safe to free it immediately.
[16:35:05 CEST] <BtbN> Need a sample with frame-reordering
[16:35:08 CEST] <nevcairiel> you can free the input after cuvidParseVideoData yes
[16:38:11 CEST] <nevcairiel> and every ordinary h264 clip should have re-ordering
[16:38:30 CEST] <nevcairiel> as long as it has b frames
[16:38:37 CEST] <nevcairiel> which is like perfectly normal
[16:40:53 CEST] <BtbN> The sample i picked was I/P only
[16:45:18 CEST] <BtbN> Interesting, with this other sample it tries to open the decoder two times with a width/height of 0, which fails. Is that normal during the initial probing?
[16:45:37 CEST] <BtbN> The third attempt has w/h and works fine.
[16:45:47 CEST] <nevcairiel> you shouldnt expect to have valid w/h for h264
[16:46:14 CEST] <nevcairiel> the cuvid API should be fine to handle this, create only the parser first, and when it calls the configure callback, create the decoder
[16:46:48 CEST] <nevcairiel> the sequence callback, i mean
[16:46:56 CEST] <BtbN> ah. So that's what it's for.
[16:50:19 CEST] <michaelni> ubitux, found a crash: ./ffmpeg    -i ~/tickets/4074/mpegts_with_dvbsubs.ts
[16:51:45 CEST] <michaelni> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4074/mpegts_with_dvbsubs.ts
[16:51:51 CEST] <ubitux> thanks :)
[16:52:30 CEST] <michaelni> the sample you pointed at from the commit worked under valgrind
[16:52:46 CEST] <prelude2004c> DHE , sorry i keep bothering and I don't like to do that but i am stuck using the GIT version .. vdpau has a problem on 3.0.1 and your patch doesn't work on that for me to test.. but the GIT version doesn't see the closed caption data on the input and the 3.0.1. and 3.0.2 does
[16:53:34 CEST] <prelude2004c> I need to see the closed caption data on the input stream in order to try and get closed caption working ( am still waiting for the time to tick down to see how your patch works today using nvenc instead of piping it to nvtranscoder )
[16:54:03 CEST] <DHE> and the mpegts patch doesn't work in the 3.0 versions?
[16:54:05 CEST] <ubitux> michaelni: cool ok, thanks
[16:54:15 CEST] <DHE> or perhaps, why does git have this regression?
[17:05:58 CEST] <prelude2004c> i can't test in the 3.0 because vdpau gives me errors and wont run in the 3.01
[17:06:33 CEST] <prelude2004c> so i can' move to 3.0.1 to test the close caption and your code.. .and i can't move out of git because i need vdpau and close caption does not work.. i have 2 different ffmpegs both having different issues and they are not consistent with eachother
[17:14:06 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07master:ad72d7d299c4: avformat: Copy properties from internal context
[17:14:50 CEST] <michaelni> prelude2004c, close caption might work too after "Copy properties from internal context" 
[17:15:23 CEST] <michaelni> it should copy FF_CODEC_PROPERTY_CLOSED_CAPTIONS too
[17:15:46 CEST] <prelude2004c> how do i do that ? 
[17:16:03 CEST] <prelude2004c> -scodec copy ?
[17:16:07 CEST] <prelude2004c> i am trying with that
[17:18:36 CEST] <nevcairiel> CC always worked, its just a cosmetical thing
[17:19:30 CEST] <prelude2004c> how come i can't get CC on my screen ? i am soo confused by this
[17:19:40 CEST] <prelude2004c> i am using nvenc to encode the content
[17:20:21 CEST] <prelude2004c> but once i decode it with CPU or vdpau it should be able to -scopy codec right ? and then if i encode it with closed caption again... this stuff is confusing me with all the different versions
[17:26:34 CEST] <michaelni> ubitux, tell me once you fixed the crash, ive seen more crashes but i assumes that they are most ikely duplicates
[17:27:03 CEST] <ubitux> michaelni: you can retry
[17:27:18 CEST] <ubitux> mateo` and i just fixed the flv-demux fate test
[17:30:20 CEST] <ubitux> fate passes
[17:30:27 CEST] <mateo`> :D
[17:31:10 CEST] <ubitux> so mmh, in the parser, we added a copy of the sps/pps from the h264 context to the local sps/pps in the parser context
[17:31:28 CEST] <ubitux> the h264context is going to go away from the parser in later commits (after all sub struct are moved into the parser context)
[17:31:55 CEST] <ubitux> but in the meantime, the inconsistency between the 2 sps/pps was causing fate issues
[17:32:15 CEST] <ubitux> that copy will need to go away in a later merge commit
[17:35:35 CEST] <michaelni> ubitux another crash: ./ffmpeg -i /home/michael/tickets//4851/2015-09-14t12.47.26.avi -f null -
[17:37:08 CEST] <michaelni> ffmpeg-bugs/trac/ticket4851/2015-09-14t12.47.26.avi
[17:37:16 CEST] <michaelni> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4851/2015-09-14t12.47.26.avi
[17:46:21 CEST] <ubitux> michaelni: no crash here
[17:46:30 CEST] <ubitux> ah my bad
[17:46:33 CEST] <ubitux> it does
[18:04:07 CEST] <ubitux> michaelni: http://sprunge.us/ROOK seems to fix it, i pushed in my branch
[18:08:27 CEST] <michaelni> why is pps not set after the first slice ?
[18:13:05 CEST] <michaelni> if the first slice had a pps why is it not set anymore (this could be a race condition as this is shared between threads)
[18:14:19 CEST] <michaelni> also speaking about the parser, it seems there are differences (just dumping all i know as i have to go afk for an hour soon)
[18:14:31 CEST] <michaelni> ./ffmpeg -fdebug +ts -i issue2.ts -vframes 12 -f null - 2>&1 | egrep 'read_frame_internal stream=' | sed 's/@.*]//'
[18:15:04 CEST] <michaelni> http://samples.ffmpeg.org/MPEG-VOB/transport/issue2.ts
[18:15:06 CEST] <ubitux> i don't know for the first slice, but i guess i should investigate
[18:15:15 CEST] <ubitux> about the differences that's not surprising
[18:15:26 CEST] <ubitux> it's going to change in the following commits
[18:16:02 CEST] <ubitux> it's likely because of the discrepancy between the h264context and its subpart being slowly extracted
[18:16:05 CEST] <michaelni> about the parser seems some flags and dts are lost in above diff
[18:20:57 CEST] <ubitux> well, i guess i'll get done later with it
[18:21:16 CEST] <ubitux> (help welcome ofc)
[18:21:56 CEST] <michaelni> ok above is all i know, (saw more crashes but i assume they are duplicates) ill go afk for a bit
[18:23:06 CEST] <ubitux> thanks a lot for the testing
[18:29:00 CEST] <ubitux> it seems there are 2 more sensible commits in the batch
[18:29:14 CEST] <ubitux> actually 3
[18:30:08 CEST] <michaelni> ubitux, i see some changes in remove_pps/sps they might be related to the pps disapearance
[18:30:58 CEST] <michaelni> also if it cannot occur with slice threads then it might be safe 
[18:40:26 CEST] <mateo`> michaelni: are you refering to this chunk https://github.com/ubitux/FFmpeg/commit/8e5d5eff1cbb77fe5b294ddac7e7da0e04252a69#diff-1a9e4208aec077c9088839326b672cdfR579 ?
[18:54:53 CEST] <michaelni> mateo`, yes also theres a 2nd one IIRC
[19:30:03 CEST] <cone-114> ffmpeg 03Derek Buitenhuis 07master:cc4ab320cf0e: MAINTAINERS: Remove myself
[19:30:55 CEST] <kierank> and there we go
[19:31:05 CEST] <kierank> sad times
[19:31:26 CEST] <BBB> I agree :(
[19:31:33 CEST] <BBB> his point that nothing in the meeting happened is true
[19:31:50 CEST] <BBB> nothing *happened in the meeting
[19:34:19 CEST] <iive> and what should have happened?
[19:36:34 CEST] <ubitux> BBB: that's not what he said
[19:36:45 CEST] <ubitux> he said it didn't change his feelings :p
[19:37:13 CEST] <BBB> isnt that the same thing?
[19:37:36 CEST] <ubitux> many unrelated things could have happened unrelated to his feelings
[19:37:56 CEST] <ubitux> or maybe it wasn't enough either, or in the wrong direction
[19:47:02 CEST] <BBB> well, I feel extremely sad about it
[19:59:43 CEST] <Compn> BBB : dont, you did what you could.
[19:59:50 CEST] <iive> BBB: you are aware that Derek's "leaving" of the project is attempt to manipulate you, by exploiting exactly these feeling.
[20:00:12 CEST] <BBB> I doubt that& :(
[20:00:28 CEST] <Compn> i've seen devs come and go. it happens, its sad, but new devs come , the sadness subsides
[20:00:29 CEST] <iive> it's not even the first time when this have been done in FFmpeg
[20:00:41 CEST] <Compn> iive : enough conspiracies 
[20:00:53 CEST] <iive> I hope you remember that Mans also left in similar fashion.
[20:00:54 CEST] <Compn> iive : how many devs , do you have a count? have left ffmpeg ?
[20:01:08 CEST] <Compn> and how many new devs have joined since then ? ;p
[20:01:25 CEST] <Compn> work on a project until it ceases to be fun, then you find new fun things to do
[20:13:26 CEST] <iive> Compn: I'm not worried for the developers who leave with a lot of noise and drama. 
[20:13:51 CEST] <iive> I'm far more concerned for these who do it quietly.
[20:49:11 CEST] <durandal_1707> iive: and you?
[20:49:54 CEST] <iive> ?
[20:50:30 CEST] <durandal_1707> you kind of left too
[20:57:09 CEST] <Shiz> lol
[20:57:53 CEST] <Shiz> what an attitude
[20:57:58 CEST] <BBB> Compn: Im aware of this, I mean, of course people come and go, thats life - but that doesnt mean I cant be sad when people leave for preventable reasons
[20:58:31 CEST] <BBB> Compn: Im genuinely sad because a good dev who was also a nice guy, left the project. thats totally normal if you ask me :)
[20:59:29 CEST] <relaxed> He left because this project lacks a real leader.
[20:59:39 CEST] <Compn> durandal_1707 : iive still maintains xvmc code
[20:59:47 CEST] <Compn> he is maintainer *
[21:00:00 CEST] <Shiz> i don't think what this project needs is baseless speculation on why someone left when he outlined his reasons fairly clearly
[21:00:24 CEST] <Compn> i'm sad he left libav project too
[21:02:26 CEST] <relaxed> libav forked for the same reason.
[21:02:54 CEST] <Compn> relaxed : so why did daemon leave libav?
[21:03:26 CEST] <Compn> Shiz : obviously . drama is stupid. rumors are stupid
[21:03:30 CEST] <Compn> why cant people just code
[21:03:43 CEST] <Shiz> turns out people are more than just codebots
[21:03:49 CEST] <Compn> fools
[21:04:39 CEST] <iive> that's actually the root of the problem :)
[21:22:17 CEST] <durandal_1707> xvmc is still used?
[21:22:49 CEST] <iive> still works, last time i tried it.
[21:23:06 CEST] <Shiz> maintainer doesn't mean muh if the code never changes
[21:23:26 CEST] <durandal_1707> when whas that?
[21:23:33 CEST] <relaxed> 1999
[21:23:44 CEST] <iive> now you are mean.
[21:23:45 CEST] <BBB> the sad thing is that for me, libav prooves that doing something about this wont have any fundamental consequences
[21:35:00 CEST] <iive> BBB: what would you have done, if you were not only project leader, but benevolent dictator for life of ffmpeg?
[21:37:14 CEST] <durandal_1707> lies
[21:37:55 CEST] <ubitux> 21:03 <@Compn> why cant people just code // do you? ;)
[21:38:59 CEST] <Compn> i have committed patches in the code ;p
[21:42:31 CEST] <Compn> i'm still sad fiona left
[21:43:00 CEST] <Compn> i miss gabu and arpi too
[21:47:08 CEST] <ubitux> "make mpl^Wffmpeg great again!"
[21:49:10 CEST] <iive> ubitux:  :) http://imgur.com/ET66pUw
[21:55:45 CEST] <relaxed> iive: :) http://imgur.com/dj6ax5Y
[21:56:37 CEST] Action: iive feels urge to drink some cola
[21:56:38 CEST] <Compn> both gabu and arpi worked on ffmpeg as well
[21:56:40 CEST] Action: Compn afk
[21:56:48 CEST] <iive> no gabu didn't
[21:58:42 CEST] <iive> i'm not sure about arpi...
[22:03:25 CEST] <ubitux> ~58 commits
[22:08:26 CEST] <prelude2004c> hi DHE , any other updates for the 26.5 hour thing ? 
[22:09:12 CEST] <iive> is that the mpeg-ts timestamps wrap around thing?
[22:12:03 CEST] <BtbN> CUDA is amazingly bad at error reporting.
[22:12:15 CEST] <BtbN> "Invalid parameter!" Yes, i just passed you like 200 of those....
[22:12:51 CEST] <iive> this reminds me of an idea I had some time ago...
[22:12:57 CEST] <ubitux> it's just missing a 's'
[22:13:06 CEST] <ubitux> why are you complaining so much for a typo :s
[22:13:29 CEST] <ubitux> oh you mean some are valid
[22:13:35 CEST] <ubitux> then message might be accurate
[22:44:24 CEST] <cone-114> ffmpeg 03Paul B Mahol 07master:e8a236add82e: avcodec/magicyuv: set correct size of last slice for each plane
[22:49:24 CEST] <jamrial> "iive  and what should have happened?"
[22:49:32 CEST] <jamrial> stop making questions you already know the answer for
[22:50:09 CEST] <iive> i just want straight honest answer
[22:51:09 CEST] <jamrial> we should have discussed and found a solution to carl's behavior, which was the entire point of the meeting
[22:51:39 CEST] <jamrial> and you knew it. we talked about it the day the meeting was called
[22:51:45 CEST] <jamrial> so why ask about it?
[22:52:43 CEST] <iive> jamrial: i don't remember such point in the message that assembled the meeting.
[22:52:44 CEST] <durandal_1707> point was that someone would call a vote to ban Carl for day/two
[22:53:29 CEST] <jamrial> iive: not the email, the chat. stop pretending to be unaware of everything
[22:54:37 CEST] <jamrial> derek is right, nothing gets done here. people can ignore rules and be a dick to others and nothing will happen
[22:55:07 CEST] <iive> jamrial: The think is, when I say it straight, people accuse me of spitting conspiracies.
[22:55:35 CEST] <jamrial> i don't do it, and don't recall anyone do it, so say it straight
[22:55:36 CEST] <durandal_1707> I will call a vote
[22:55:53 CEST] <jamrial> *doing
[22:57:58 CEST] <jamrial> durandal_1707: the meeting was meant to discuss about it, yet when i asked to do it nobody cared
[22:58:08 CEST] <jamrial> a vote before anything can be discussed and arguments made in favor or against will not get much support
[22:58:09 CEST] <iive> jamrial: the thing is, Derek is one of these who are "dick to others". He always jumps in the fray when there is some dispute with Carl.
[22:58:47 CEST] <durandal_1707> please
[22:59:01 CEST] <nevcairiel> It's irrelevant who else is to blame, the mail was out of line and that's that. No one is defending anyone elses behavior 
[22:59:58 CEST] <nevcairiel> Saying he did bad things too as an excuse for such behavior is not going to work
[23:00:44 CEST] <jamrial> iive: go on then, defend carl's reply to derek's, or alternatively the other email literally disregarding a polite request to follow a fucking basic rule he insists on ignoring
[23:01:00 CEST] <jamrial> you're an expert victimizing aggressors after all
[23:02:28 CEST] <DHE> prelude2004c: I'm confused, because it's working okay for me...
[23:04:09 CEST] <iive> jamrial: would you remind me, who is the other aggressor i've victimized?
[23:04:34 CEST] <jamrial> again asking questions you know the answer for?
[23:04:47 CEST] <iive> jamrial: i really can't recall...
[23:06:22 CEST] <jamrial> so you wont defend carl's behavior. we then agree somethign should be done about it?
[23:07:35 CEST] <iive> answer my question please. while i'm typing a response.
[23:08:07 CEST] <jamrial> there's no "other", just the one
[23:08:24 CEST] <iive> <iive> jamrial: would you remind me, who is the other aggressor i've victimized?
[23:12:02 CEST] <prelude2004c> very strange... 
[23:15:46 CEST] <prelude2004c> so tell me.. this is my code right now 
[23:16:03 CEST] <prelude2004c> ${ffmpeg} -hwaccel vdpau -threads 1 -v 32 -i "$stream" $mapping -c:s copy -c:v nvenc -2pass 1 -s 1280x720 -b:v 1800k -preset llhq -minrate 1k -maxrate 2200k -bufsize 3000k -bf 1 -refs 1 -g 180 -r 30 -af "aresample=async=1000,volume=10dB" $audio -frame_drop_threshold 1.0 -hls_time 6 -hls_flags delete_segments -start_number $start -hls_list_size 5 ${HLS_PATH_FILES}/${CHN}/${CHN}2M.m3u8 2>/var/log/channels/${CHN}/720p.txt
[23:16:29 CEST] <prelude2004c> very simple.... how do i get closed caption out of it ? the c:s copy should do it ? or maybe not.. do i have to basically port the closed caption data form h264 > nvenc ? 
[23:16:53 CEST] <prelude2004c> because i don't see any closed caption data... and what is odd.. the git version shows no closed caption data while the version 3.0.1 does on the input
[23:20:07 CEST] <iive> jamrial: i'm waiting.
[23:20:20 CEST] <jamrial> you missed my reply above?
[23:20:23 CEST] <jamrial> i'm the one waiting here
[23:21:21 CEST] Action: mateo` popcorn
[23:21:43 CEST] <iive> jamrial: you accused me of something you cannot prove. I do take offence in that.
[23:22:17 CEST] <iive> because the last "aggressor" I remember defending is michael.
[23:23:07 CEST] <jamrial> i said you're an expert on victimizing agressors, talking of course about carl. you wrongly assumed i was talking about someone else, and i let you know
[23:23:36 CEST] <jamrial> in any case, you're again derailing conversations and avoiding answering questions
[23:23:51 CEST] <iive> agressors is not singular. and your words imply pattern of behaviour.
[23:24:40 CEST] <jamrial> case in point, you insist on derailing it with petty excuses
[23:24:54 CEST] <iive> it's just on point
[23:25:19 CEST] <jamrial> i'm still waiting. since you are not defending carl's emails, do we agree something should be done about it?
[23:25:26 CEST] <iive> because you are talking about behaviour of carl, based on a single incident.
[23:28:48 CEST] <nevcairiel> its a pattern of behavior culminating in one very aggressive outburst, and even single incidents should not be ignored or belittled
[23:30:42 CEST] <iive> some time ago, I watched a video where a far kid punched a smaller kid hard. Obviously the fat kid is a bully.
[23:31:43 CEST] <iive> funny thing. The comments were actually explaining that the fat kid is the one been bullied and finally fighting back. There's been a longer version of the incident.
[23:32:41 CEST] <jamrial> stop talking, iive
[23:35:12 CEST] <nevcairiel> like I said earlier, previous behavior of other people is no excuse, and this is not a school yard. if someone feels bullied or feels like someone is bullying someone else, they can call for equal handling like this matter
[23:35:17 CEST] <nevcairiel> for now, we deal with the person at hand
[23:36:45 CEST] <iive> nevcairiel: school yard is actually very good description.
[23:37:36 CEST] <RiCON> in a school yard there are usually responsible people
[23:40:15 CEST] <ubitux> would be nice to use the little energy we have left for the important technical aspect of the project instead of these weekly/daily braindead and endless discussions
[23:40:42 CEST] <ubitux> these discussions should just move to the appropriate geopoliticophilosophicosocial subreddit
[23:40:59 CEST] <ubitux> "FFmpeg development channel", /topic
[23:41:11 CEST] <iive> no, it is bad idea these thing to remain unspoken.
[23:41:27 CEST] <iive> they have to be vented, even if they don't smell good.
[23:41:28 CEST] <ubitux> it's not fucking unspoken, you raise that topic every single time you have an occasion
[23:43:10 CEST] <jsebechlebsky> Hello, I would like to ask - how can I build doxygen documentation of ffmpeg? (I suppose there is some configure option / makefile target)
[23:44:00 CEST] <ubitux> mmh
[23:44:04 CEST] <ubitux> make doc/doxy/html maybe
[23:44:16 CEST] <ubitux> check around doc/Makefile if it's not the case
[23:46:39 CEST] <jsebechlebsky> Thanks! I found it it doc/Makefile - it's 'make apidoc'
[23:47:16 CEST] <ubitux> ah yeah, much cleaner
[23:49:24 CEST] <michaelni> ubitux, about pps/sps "7.4.1.2.1 Order of sequence and picture parameter set RBSPs and their activation" lists some basic rules
[23:50:01 CEST] <michaelni> in relatio to that though theres one special case to keep in mind at least, there can be 2 access units in a AVPacket (2 fields in mov )
[23:50:10 CEST] <ubitux> but i suppose most of the code i have to deal with is about going back on its feet when there is a violation of some sort?
[23:50:25 CEST] <ubitux> (violation/bitstream error)
[23:50:49 CEST] <ubitux> but thanks for the ref, that will help
[23:51:14 CEST] <michaelni> i dont know, i didnt really look at the diff but it seems after the merge a pps/sps in the middle of a field (this is not allowed) resets the activated *ps (this is not what the spec says)
[23:52:03 CEST] <michaelni> ill reread the spec just to be sure iam not misremembering
[23:52:39 CEST] <ubitux> i'll continue working on this merge tomorrow, hopefully i can get it done properly
[00:00:00 CEST] --- Fri Jun  3 2016