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

[burek]

[06:04:11 CET] <wm4> "We provide our custom Boost libraries." WAT
[06:06:04 CET] <Compn> haha
[06:06:06 CET] <Compn> wheres that
[06:07:55 CET] <wm4> one of the libturing threads on ffmpeg-devel
[07:46:18 CET] <wm4> michaelni: ok to push "doc: clarify development rules"?
[09:24:31 CET] <kierank> wm4: wow
[09:25:08 CET] <wm4> kierank: yes?
[09:25:29 CET] <kierank> Custom boost
[09:25:31 CET] <kierank> Insane
[09:26:15 CET] <wm4> yeah, I feel slightly offended that they're using Turing's name
[09:31:01 CET] <JEEB> oh that thing
[09:38:55 CET] <jkqxz> As long as they actually build the things in so that it doesn't interfere with anything else then whatever.
[09:46:32 CET] <cone-291> ffmpeg 03Carl Eugen Hoyos 07master:d100dc6c9955: Makefile: Clean compat subdirectory.
[11:29:43 CET] <wm4> I'm still trying to merge those filter init patches
[11:29:55 CET] <wm4> I think many timestamp issues are caused by "ffmpeg: do packet ts rescaling in write_packet()"
[11:30:18 CET] <wm4> the main issue is that a muxer can update the timebases in write_headers
[11:30:43 CET] <nevcairiel> didnt you compensate for that by moving the call already
[11:30:49 CET] <wm4> before the patches write_headers was called before even encoding something - now it's called only after most of that happens for every AVStream to mux
[11:31:02 CET] <wm4> and that compensation works only if there's 1 stream to mux
[11:31:49 CET] <wm4> if there are multiple streams, then mux_timebase can only be correctly set for the last stream that's initialized
[11:31:58 CET] <nevcairiel> so the main problem is that timestamps vary in precision a bit, because they are rescaled in one extra timebase in between?
[11:34:25 CET] <wm4> yes
[11:34:42 CET] <nevcairiel> it makes sense for muxers to only determine the timebase in write_headers, only then do they know the stream properties
[11:35:09 CET] <wm4> it's the current API anyway, so no changing that
[11:35:28 CET] <wm4> it often depends on codec parameters too
[11:35:38 CET] <nevcairiel> yeah, audio sample rates and whatnot
[11:36:04 CET] <wm4> I wonder if setting a random high timebase would hurt
[11:36:17 CET] <wm4> like AV_TIME_BASE
[11:36:35 CET] <nevcairiel> and the problem then is that with multiple streams you already have a bunch of packets queued up before you know the final timebase?
[11:36:51 CET] <wm4> yes, potentially
[11:37:30 CET] <michaelni> wm4, about "doc: clarify development rules", i dont think i have the authority to say ok or not ok. but it seems some people on the ML were not in favor of the patch
[11:37:54 CET] <wm4> michaelni: their comments were invalid
[11:38:12 CET] <wm4> they were complaining about the current dev policy, which was offtopic
[11:38:22 CET] <wm4> so basically nobody rejected/approved the patch
[11:38:33 CET] <wm4> and MAINTAINERS has no maintainer
[11:38:39 CET] <wm4> what am I supposed to do
[11:39:00 CET] <nevcairiel> instead of setting mux_timebase to some guessed output timebase, why not use the input timebase?
[11:39:16 CET] <nevcairiel> that still avoids a rescale, potentially
[11:39:29 CET] <wm4> nevcairiel: that's also "random" (because the timebase can be changed by filters or encoder), but yeah
[11:39:54 CET] <nevcairiel> at the time it is set, the filters would already have initialized it
[11:39:58 CET] <wm4> I'm not really sure what timebase it uses now
[11:40:22 CET] <wm4> filters are lazily initialized, and I think there can be multiple filter graphs
[11:40:25 CET] <nevcairiel> if the timebase changes in the middle of encoding for some reason, it w ould never compensate either way
[11:41:24 CET] <nevcairiel> basically you have filter timebase -> mux timebase -> output timebase
[11:41:28 CET] <nevcairiel> ideally two of those are the same
[11:41:38 CET] <nevcairiel> if mux and output cant really be the same, why not filter and mux
[11:42:39 CET] <wm4> hm yeah I have no idea where it initializes the timebase before that
[11:43:47 CET] <nevcairiel> with the new initialization order, I would think at the time the outputstream is being created, you already know the final and proper input timebase
[11:44:09 CET] <wm4> dammit why does ffmpeg.c have to be (almost) a single file
[11:46:46 CET] <wm4> "enc_ctx->time_base = av_inv_q(ost->frame_rate);" interesting
[11:47:14 CET] <wm4> (not sure if that's a good idea over the filter time_base, but that's what it does)
[11:47:37 CET] <wm4> (though it falls back to filter timebase if unset)
[11:49:19 CET] <wm4> still getting a fate failure with subtitles lol
[11:49:53 CET] <michaelni> wm4, i dont know but if you dont want anyone to dispute the validity of a change in the future then a vote or clear consensus with sufficient time for people to comment may be needed. It may be enough to repost with a clear statement that if noone objects in X days it will be pushed and will be part of the policy people have to comply to or something
[11:50:19 CET] <wm4> michaelni: I'm not sure if you're trolling me
[11:51:00 CET] <wm4> surely we shouldn't have to vote for patches that are not properly reviewed
[11:52:00 CET] <wm4> demuxer+ffmpeg -> ist_index:1 type:subtitle pkt_pts:1832831 pkt_pts_time:20.3648 pkt_dts:1832831 pkt_dts_time:20.3648 off:-100100 off_time:-0.1001
[11:52:22 CET] <wm4> muxer <- type:subtitle pkt_pts:2037 pkt_pts_time:20.37 pkt_dts:2037 pkt_dts_time:20.37 size:70
[11:52:46 CET] <wm4> this was 20.36 before my change
[11:52:49 CET] <michaelni> wm4 i was just tryng to reply to "<wm4> what am I supposed to do", i dont want to be involved in this at all
[11:52:54 CET] <wm4> so rounding is done differently, "somewhere"
[11:53:42 CET] <wm4> michaelni: then why are you
[11:54:09 CET] <nevcairiel> which timebase are you using now for mux
[11:54:32 CET] <wm4> I mean, this is quite funny, I'm trying to clarify the rules, yet I don't know if I can push the clarification because nobody knows the rules
[11:54:47 CET] <wm4> nevcairiel: the encoder's timebase, which for subtitles is always 1/000
[11:54:48 CET] <michaelni> wm4, because you pinged me "<wm4> michaelni: ok to push "doc: clarify development rules"?"
[11:54:51 CET] <wm4> err, 1/1000
[11:55:22 CET] <wm4> michaelni: point taken
[11:55:50 CET] <wm4> you're still the defacto project leader, though
[11:56:09 CET] <wm4> because there's nobody else
[11:56:39 CET] <wm4> hm, subtitle timebase of 1/90000 can only be wrong due to things like dvb subs too
[11:58:58 CET] <nevcairiel> if mux_timebase is 1/1000 and subtitles use 1/1000 for encoding, how cna it end up wrong
[11:59:24 CET] <nevcairiel> oh
[11:59:27 CET] <nevcairiel> subtitles use AV_TIME_BASE
[11:59:29 CET] <nevcairiel> not 1/1000
[12:00:02 CET] <wm4> where?
[12:00:10 CET] <nevcairiel> in do_subtitle_out
[12:00:11 CET] <wm4> the encoder context gets 1/1000
[12:00:15 CET] <nevcairiel> pkt.pts  = av_rescale_q(sub->pts, AV_TIME_BASE_Q, ost->mux_timebase);
[12:00:46 CET] <wm4> ah
[12:01:02 CET] <wm4> just tried with the input timebase
[12:01:03 CET] <nevcairiel> not sure whatever is in the context, but thats what it uses
[12:01:04 CET] <wm4> -Dialogue: 0,0:02:23.48,0:02:26.53,Default,,0,0,0,,C 09...\N8=0 <=>3> 2 at 5<5.
[12:01:04 CET] <wm4> +Dialogue: 0,0:02:23.48,0:02:26.52,Default,,0,0,0,,C 09...\N8=0 <=>3> 2 at 5<5
[12:02:05 CET] <wm4> setting the encoder tb to AV_TIME_BASE_Q makes it pass
[12:02:06 CET] <wm4> whatever
[12:02:25 CET] <nevcairiel> i guess subtitle encoders just never use the tb?
[12:02:30 CET] <wm4> (mux_timebase is the same as the encoder tb in my current changes)
[12:02:40 CET] <wm4> quite possible
[12:03:02 CET] <nevcairiel> we moved all possible formats to out-of-band timestamps
[12:05:40 CET] <nevcairiel> I imagine it worked in libav because st->timebase is just set to enc_ctx->timebase somewhere
[12:05:44 CET] <nevcairiel> and we  dont do that for reasons
[12:05:54 CET] <wm4> or libav doesn't even test that
[12:06:04 CET] <nevcairiel> also possible
[12:06:29 CET] <wm4> now binsub-movtextenc failed
[12:06:32 CET] <wm4> with a changed hash
[12:06:37 CET] <nevcairiel> but using enc_ctx timebase (and whatever equaivalent for streamcopy) for mux timebase is probably ok
[12:07:24 CET] <nevcairiel> what does that test?
[12:07:25 CET] <wm4> this test passes if I use the input tb
[12:07:35 CET] <wm4> ffmpeg -nostdin -nostats -cpuflags all -hwaccel none -threads 1 -thread_type frame+slice -i ../fate//sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov md5:
[12:07:59 CET] <wm4> probably rounding
[12:09:59 CET] <nevcairiel> depending on what exactly it writes, it may also pick up the changed encoder timebase
[12:11:15 CET] <wm4> uh
[12:11:19 CET] <wm4> the mp4 files are the same
[12:11:42 CET] <wm4> right, because I did something dumb
[12:12:53 CET] <wm4> -time_base=1/1000
[12:12:53 CET] <wm4> +time_base=1/1000000
[12:12:54 CET] <wm4> yep
[12:13:44 CET] <wm4> I wish fate had a way to resume from a given point
[12:14:07 CET] <nevcairiel> makefile based, no such luck
[12:17:12 CET] <wm4> aaaaand sub2video fails
[12:17:22 CET] <wm4> probably just changed timebase
[12:23:16 CET] <wm4> and fate-copy-trac4914-avi (just mentioning because I find the name of the test funny)
[12:23:32 CET] <BtbN> Are you at the lazy filter init regressions again?
[12:23:37 CET] <wm4> yes
[12:23:42 CET] <BtbN> Sounds like fun
[12:58:48 CET] <BtbN> I really wonder what the hell kind of encoding cl uses. winpty managed to convert it to something useful, but I can't find any input format for iconv that converts it to utf-8
[12:59:17 CET] <wm4> so I have no idea why fate-copy-trac4914-avi failed, some packets got reordered and some timestamps change slightly
[12:59:30 CET] <wm4> I'll just assume nobody will object
[12:59:41 CET] <wm4> BtbN: cl?
[12:59:47 CET] <BtbN> MSVC compiler
[12:59:56 CET] <wm4> probably your local 8 bit codepage
[13:00:01 CET] <BtbN> nope
[13:00:21 CET] <wm4> maybe iconv doesn't understand it correctly
[13:00:32 CET] <BtbN> windows-1252 to utf-8 doesn't work
[13:00:40 CET] <wm4> meaning?
[13:01:16 CET] <BtbN> cl |& head -n1 | iconv -f windows-1252 -t utf-8  ->  iconv: (stdin):1:64: cannot convert
[13:02:21 CET] <wm4> that means it uses bytes not defined by that codepage?
[13:02:30 CET] <BtbN> I guess so, yes
[13:02:39 CET] <BtbN> I tried basically all codepages there are, none works
[13:04:30 CET] <BtbN> Might be CP20273/windows-1141
[13:04:35 CET] <BtbN> which iconv does indeed not support
[13:05:17 CET] <wm4> what's the offending byte?
[13:05:27 CET] <BtbN> The one for ü
[13:06:34 CET] <BtbN> https://bpaste.net/show/04590852adb2
[13:07:02 CET] <wm4> 0x81?
[13:07:04 CET] <BtbN> yes
[13:07:36 CET] <BtbN> Might as well just say fuck it and strip away all non-utf8 characters from the cc ident...
[13:07:51 CET] <BtbN> They use the local codepage per language anyway, so adding logic for that to configure would be insane
[13:08:00 CET] <wm4> heh
[13:09:24 CET] <BtbN> chcp says I'm on CP850
[13:09:55 CET] <BtbN> indeed, iconv -f CP850 -t utf-8 works
[13:10:14 CET] <BtbN> That's "Multilingual (Latin I)"
[13:10:20 CET] <BtbN> So maybe it does work for more than German
[13:11:08 CET] <nevcairiel> 850 has ü at 0x81
[13:13:02 CET] <wm4> demuxer+ffmpeg -> ist_index:0 type:video pkt_pts:537660 pkt_pts_time:5.974 pkt_dts:531654 pkt_dts_time:5.90727 off:-419044 off_time:-0.419044
[13:13:02 CET] <wm4> [mpeg @ 0x55b130cae360] Non-monotonous DTS in output stream 0:0; previous: 531531, current: 531531; changing to 531532. This may result in incorrect timestamps in the output file.
[13:13:02 CET] <wm4> muxer <- type:videdemuxer+ffmpeg -> ist_index:0 type:video pkt_pts:537660 pkt_pts_time:5.974 pkt_dts:531654 pkt_dts_time:5.90727 off:-419044 off_time:-0.419044
[13:13:02 CET] <wm4> [mpeg @ 0x55b130cae360] Non-monotonous DTS in output stream 0:0; previous: 531531, current: 531531; changing to 531532. This may result in incorrect timestamps in the output file.
[13:13:04 CET] <wm4> muxer <- type:video pkt_pts:537537 pkt_pts_time:5.97263 pkt_dts:531532 pkt_dts_time:5.90591 size:14002
[13:13:07 CET] <wm4> o pkt_pts:537537 pkt_pts_time:5.97263 pkt_dts:531532 pkt_dts_time:5.90591 size:14002
[13:13:11 CET] <wm4> crap
[13:13:14 CET] <wm4> (pasted a bit too much)
[13:13:33 CET] <wm4> anyway, I'm probably missing how timestamp rounding in ffmpeg.c works
[13:14:13 CET] <wm4> these warnings are new with the rescale changes libav patch + setting mux_timebase to encoder output
[13:43:27 CET] <cone-645> ffmpeg 03Carl Eugen Hoyos 07master:a2ca9e11ff71: Makefile: Clean compat/atomics/pthread subdirectory.
[14:03:43 CET] <Compn> wm4 : since you want to change policy, you need a majority of active devs to agree with you
[14:04:08 CET] <Compn> <insert definition of active here> :P
[14:04:11 CET] <Compn> or just devs..
[14:04:20 CET] <wm4> Compn: for the 100ths time, I don't want to change policy
[14:04:29 CET] <wm4> at least not with that patch
[14:04:37 CET] <Compn> i havent read the patch , let me read it... :D
[14:04:42 CET] <wm4> I'm trying to find out what the fucking rules are in this project
[14:05:58 CET] <Compn> well you are setting the time periods of various things. including what an active developer is
[14:06:42 CET] <Compn> just the 6 month thing i guess. i'm not sure what would be a good timeframe
[14:06:54 CET] <wm4> well that's as arbitrary as the actual policy, apparently
[14:07:32 CET] <Compn> also the line about 'this only applies to people with git access' could go, as its redundant to reality
[14:08:17 CET] <cone-645> ffmpeg 03Michael Niedermayer 07master:2c00b3730240: avcodec/avpacket: Check metadata key in av_packet_unpack_dictionary()
[14:08:18 CET] <cone-645> ffmpeg 03Michael Niedermayer 07master:4bd3f1ce3e68: avcodec/h264_direct: Fix runtime error: left shift of negative value -14
[14:08:19 CET] <cone-645> ffmpeg 03Michael Niedermayer 07master:7b5ff7d57355: avcodec/vp8: Check for bitsteam end in decode_mb_row_no_filter()
[14:08:30 CET] <Compn> i mean you have to agree, no time frame set > 6 months timeframe set is technically a change in policy. please be careful with your words :P
[14:08:36 CET] <wm4> well the text is directed to external contributors too
[14:08:51 CET] <wm4> Compn: I acknowledge that in my patch?
[14:10:07 CET] <Compn> external contributors , get git access when they become maintainers, usually though
[14:10:18 CET] <Compn> if that sentence makes sense
[14:11:26 CET] <Compn> to answer your question about michaelni. he very publically stated that he is not project leader (this news hit a lot of major tech news websites a while back) and will not override the consensus of the developers in the project.
[14:12:28 CET] <wm4> Compn: there's nobody else who could arbitrate
[14:12:35 CET] <Compn> thats the point
[14:12:43 CET] <wm4> that he isn't project leader is de-facto wrong, and de-facto bullshit
[14:12:59 CET] <Compn> now you're ignoring his wishes not to be project leader. thats not good
[14:13:18 CET] <Compn> the only arbitration is consensus among ffmpeg devels
[14:13:30 CET] <Compn> or ... electing a new project leader
[14:13:33 CET] <wm4> ffmpeg devs are unable to come to a consnsus
[14:13:35 CET] <Compn> by consensus of ffmpeg devs...
[14:13:41 CET] <wm4> *conensus
[14:13:47 CET] <wm4> *consensus (this time)
[14:13:48 CET] <wm4> this has been proven before
[14:14:02 CET] <wm4> project leaders are needed because of such issues
[14:14:12 CET] <Compn> then policy does not change... if there is no consensus
[14:14:37 CET] <Compn> maybe make it a suggestion in your patch
[14:14:59 CET] <Compn> "if the maintainer or author of the code has not made changes or communications within 2 years, feel free to push changes...'
[14:15:04 CET] <Compn> or 
[14:15:12 CET] <wm4> why not make it 4 years
[14:15:12 CET] <Compn> "if the maintainer or author of the code has not made changes or communications within 2 years, use your best judgement to push changes...'
[14:15:18 CET] <wm4> at least I still get michaelni for a rule violation this way
[14:15:25 CET] <Compn> i picked 2 years...
[14:15:38 CET] <Compn> since its my review of the patch , i get to pick my terms
[14:15:45 CET] <wm4> you pulled 2 years out of your ass, correct
[14:15:51 CET] <wm4> just like I did with 6 months
[14:15:55 CET] <Compn> thats how patch review works, all ass.
[14:17:20 CET] <Compn> i think all other devs here respected michaelni's wishes not to be leader. you might want to rethink your position.
[14:17:39 CET] <Compn> not that going with the crowd is required.
[14:18:21 CET] <wm4> it's not that I'm not respecting his wish
[14:18:46 CET] <wm4> but he still holds all the infrastructure, and does things like giving out new push rights or adding me to the security ML
[14:20:22 CET] <Compn> that makes him security admin and git admin, not project leader
[14:21:28 CET] <Compn> in my opinion anyhow
[14:22:50 CET] <Compn> there also might be an exception for corporate sponsored/authored code
[14:23:12 CET] <nevcairiel> only if the exception reads that we never accept it
[14:23:19 CET] <nevcairiel> because its usually terrible and horrible and awful
[14:23:21 CET] <Compn> for example, vdpau code maintainer might not be so active on our list
[14:23:36 CET] <Compn> all the @nvidia copyright in ffmpeg...
[14:29:17 CET] <Compn> by exception i mean exception to the time limit. if 2 years was used, probably dont need an exception.
[14:33:48 CET] <BtbN> Compn, what's so bad about @nvidia.com authors? The code is still LGPL, someone from nvidia adding stuff to it doesn't change that.
[14:33:58 CET] <BtbN> I very much appreciate the work from nvidia on nvenc
[14:37:05 CET] <Compn> BtbN : i agree, thats why i suggested an exemption so they could have more time to review. i'm reviewing wm4's patch...
[14:37:15 CET] <Compn> BtbN : nevcairiel is the one who said he didnt like corporate code
[14:37:39 CET] <BtbN> oh, that's what you mean by exception
[14:37:47 CET] <Compn> yea
[14:38:28 CET] <Compn> i re-read my original statement and it lacked the proper context... tried to clarify but was unsuccessful :(
[14:39:29 CET] <Compn> we americans are under constant word salad attacks... hard to form english anymore with these violations being broadcast all day
[14:39:58 CET] <Compn> please forgive my poor english :D
[14:45:45 CET] <wm4> salad attacks?
[14:47:07 CET] <wm4> I assume mixing encoding and stream copy to the same target file is completely allowed?
[14:47:43 CET] <BtbN> Of course, re-encoding video but just copying the audio seeems quite common
[14:47:55 CET] <wm4> urgh
[14:50:13 CET] <Compn> it causes many problems for vlc and other players however, because mencoder/ffmpeg dont fix timestamps sometimes when people do this
[14:51:04 CET] <wm4> no secret that ffmpeg sometimes creates broken files without any indication or warning
[14:51:41 CET] <Compn> 'warning, you are reencoding video but copying audio, this could cause problems' ?
[14:52:13 CET] <Compn> i would support this message that no one would ever read.
[14:52:21 CET] <wm4> that doesn't have to do with that, it's true in general and also streamcopy is fragile by nature
[14:52:46 CET] <Compn> why not make streamcopy robust ?
[14:56:55 CET] <wm4> Compn: because it's fragile by nature
[14:57:16 CET] <Compn> make it unnatural 
[14:57:26 CET] <Compn> control all the bitstreams.
[15:55:01 CET] <wm4> michaelni: I've updated my filter init merge patches, I think there are still some of your cases failing, while others work: https://github.com/wm4/FFmpeg/commits/filter-merge
[16:28:35 CET] <nevcairiel> wm4: doesnt the second mux_timebase set in init_output_stream override the one from init_output_stream_encode
[16:44:34 CET] <cone-645> ffmpeg 03Rick Kern 07master:70ebc05bce51: lavc/videotoolboxenc: fix symbol linking
[16:49:09 CET] <wm4> nevcairiel: forgot to remove that
[16:51:08 CET] <wm4> seems like a pretty serious oversight
[18:14:43 CET] <wm4> philipl: should cuvid be disabled on osx? (I don't know)
[18:27:50 CET] <adeeln_> durandal_1707: I'm still stuck on the probe issue. The difference file has the same size. https://gist.github.com/adl1995/5a454e565c5c053cc5908526d57b1f18 (same as yesterday)
[18:31:25 CET] <durandal_1707> give full diff
[18:31:39 CET] <durandal_1707> not diff of diff of diff...
[18:49:16 CET] <philipl> wm4: I think so. nvidia certainly don't claim to support it, although they say that about cuvid on xp too and that works.
[18:49:55 CET] <nevcairiel> noone in their right mind should claim anything works in xp
[18:49:57 CET] <philipl> I do know that the call I used to get the device being used for the opengl context is documented to only work on linux/windows, so I assume that would fail before any cuvid functionality could be tested.
[18:50:16 CET] <adeeln_> durandal_1707: I've commited the code to a separate branch and given this command: sudo git diff master > work.txt but the output file remains unchanged
[18:50:18 CET] <philipl> Sorry, that call is in mpv.
[18:50:24 CET] <philipl> In ffmpeg, there is no use of that.
[18:50:52 CET] <philipl> So, someone has to try it and see. With the one model of macbook pro that nvidia produce drivers for
[18:52:25 CET] <wm4> nevcairiel: ffmpeg works on XP
[18:52:49 CET] <nevcairiel> we dont make any claims it works anywhere, we let binary providers figure that out =p
[18:52:57 CET] <wm4> philipl: the ffmpeg cuda stuff doesn't even load the right .dylib on osx
[18:53:32 CET] <durandal_1707> adeeln_: check output of git log
[18:53:54 CET] <philipl> wm4: well then :-)
[18:54:37 CET] <philipl> It's most assuredly never been tested. Back when we linked against system libraries it would fail at configure time. Now it will always build, whether it's usable or not
[18:58:13 CET] <adeel2> durandal_1707: this is the last one: commit 77bb6835ba752bb9335d208963a53227bbb1bc63 Author: (no author) <(no author)@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b> Date:   Wed Dec 20 00:02:47 2000 +0000      New repository initialized by cvs2svn.          Originally committed as revision 1 to svn://svn.ffmpeg.org/ffmpeg/trunk
[18:59:08 CET] <nevcairiel> we use git, not svn
[19:00:05 CET] <durandal_1707> adeel2: whatever you done is wrong
[19:00:49 CET] <durandal_1707> adeel2: make proper git clone
[19:01:37 CET] <wm4> that's the first commit in the ffmpeg git repo
[19:01:39 CET] <wm4> (same hash)
[19:03:56 CET] <adeel2> durandal_1707: okay, making a new clone
[19:04:19 CET] <durandal_1707> adeel2: what was first log instead?
[19:04:31 CET] <adeel2> let me check
[19:05:12 CET] <adeel2> commit 7731b0475da706f802c004a10da1e58186509718 Author: Adeel Ahmad <adeelahmad14 at hotmail.com> Date:   Tue Feb 28 23:52:39 2017 +0500      changes
[19:05:33 CET] <adeel2> I sent the last log last time
[19:07:56 CET] <durandal_1707> and one before that?
[19:13:08 CET] <adeel2> durandal_1707: difference of first two commits: https://gist.github.com/adl1995/73b79c4b6bc655f42015f10f16d601b6 let me know if this helps
[19:17:55 CET] <atana> michaelni, ping
[19:18:42 CET] <atana> what is the next step? should I start testing or more modification is needed
[19:19:58 CET] <durandal_1707> adeel2: still bad. try diff of 3 commits
[19:25:42 CET] <durandal_1707> adeel2: git diff HEAD^3 iirc
[19:30:28 CET] <wm4> adeel2: always use a branch, then you can do "git diff master"
[19:31:48 CET] <adeel2> here is a difference of last 3 commits: https://gist.github.com/adl1995/f695c576e7a381779149d89cabbe6bc2f
[19:32:04 CET] <adeel2> not sure what 'git diff HEAD^3 iirc' means
[19:32:21 CET] <JEEB> and just fork the ffmpeg repo on github and have your own repo to which you can easily link to :P
[19:32:32 CET] <JEEB> or gitlab or whatever else, github is just the most used one
[19:32:41 CET] <adeel2> wm4: I tried creating a new branch but git diff gave the same output
[19:32:58 CET] <JEEB> yes, if you created it after you already had committed some stuff :P
[19:33:30 CET] <adeel2> JEEB: oh yeah, I did do that :D
[19:33:46 CET] <JEEB> if you are on *nix use gitk to visualize things
[19:33:50 CET] <wm4> JEEB: a github fork would actually make it harder tp sync with upstream
[19:33:53 CET] <wm4> *to
[19:34:10 CET] <JEEB> wm4: having both as remotes, with official videolan thing as "origin"
[19:34:15 CET] <wm4> because pulling/fetching would work on your forked repo instead of upstream
[19:34:30 CET] <JEEB> esp. now that he has a remote already set
[19:35:12 CET] <wm4> I'd say just learn how branches and git fetch works and how commits are "linked"
[19:35:34 CET] <wm4> and get some good tool that can visalize the current state of your repo (like gitk or whatever)
[19:35:41 CET] <wm4> *visualize
[19:36:40 CET] <adeel2> just installed gitk
[19:37:32 CET] <durandal_1707> adeel2: link doesnt work for me
[19:40:00 CET] <adeel2> durandal_1707: fixed it. Please check: https://gist.github.com/adl1995/ce17fa770dc6229a487f6dfefd40b634
[19:46:48 CET] <durandal_1707> adeel2: better start over in fresh new branch, do not modify master branch it should be same as ffmpeg
[19:48:04 CET] <adeel2> durandal_1707: do I create the new branch in seperate new fork?
[19:49:13 CET] <durandal_1707> doesnt matter
[19:49:29 CET] <durandal_1707> just make sure master is untouched
[19:49:59 CET] <adeel2> I already made my previous changes (past few days) in master branch
[19:54:29 CET] <durandal_1707> master branch should be kept untouched
[19:55:15 CET] <wm4> it's up to you, but especially if you're new with git it's probably less confusing to strictly not touch master, and work in a different branch
[19:58:04 CET] <michaelni> hi atana
[19:59:43 CET] <adeel2> durandal_1707: here's what I did: 'git checkout -b new_branch' and then 'git diff master > work.txt', the output is: https://gist.github.com/adl1995/7841f0d77e0a9e01c815011430511b24
[20:00:22 CET] <michaelni> atana, testing surely makes sense, more modifications will be needed
[20:01:04 CET] <michaelni> but it would be ideal if some testing is done between modifications so we can make sure all modifications improve things
[20:18:42 CET] <atana> michaelni, so should I proceed with the dataset we decided upon?
[20:19:40 CET] <michaelni> yes
[20:29:07 CET] <durandal_1707> adeel2: clear your master branch
[20:31:39 CET] <durandal_1707> your master branch have unwanted commits
[20:53:02 CET] <J_Darnley> Before clearing anything see if this will get what someone is looking for: git diff origin/master
[20:53:16 CET] <J_Darnley> Argh
[21:56:44 CET] <llogan> looks like site is down (for me in the US at least), but it appears to be an issue with trac server as well, so probably a networking issue we can do nothing about
[22:01:21 CET] <llogan> tracepath makes it to a telepoint ip but nothing beyond that.
[22:10:23 CET] <llogan> back now. self-talking man.
[22:43:51 CET] Action: Compn high fives llogan
[22:45:26 CET] <nevcairiel> trac works for me
[22:45:35 CET] <nevcairiel> oh right, back :p
[00:00:00 CET] --- Thu Mar  2 2017