[00:05:15 CEST] <jamrial> anyway, patch sent [09:26:49 CEST] <cone-690> ffmpeg 03Steven Liu 07master:f502bd5432c9: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [11:02:28 CEST] <superware> how can I detect (from AVFormatContext/AVStream) that the opened media is a file OR a real-time stream? [11:03:45 CEST] <funman> try seeking? [11:05:41 CEST] <superware> can't RTSP seek? [11:06:43 CEST] <funman> I guess it might [11:06:58 CEST] <JEEB> there's no flag for "live stream" in lavf as far as I know [13:44:39 CEST] <cone-690> ffmpeg 03Steven Liu 07master:bbae8d08f592: Revert "lavf/rtsp.c: Fix stimeout option not applied on http tunnel" [13:44:40 CEST] <cone-690> ffmpeg 03Signed-off-by: Jun Li 07master:1ae8a1073ba8: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [13:45:15 CEST] <nevcairiel> someone needs to stop sucking =p [13:47:12 CEST] <cone-690> ffmpeg 03Steven Liu 07master:7f78a1b1caea: Revert "lavf/rtsp.c: Fix stimeout option not applied on http tunnel" [13:47:13 CEST] <cone-690> ffmpeg 03Jun Li 07master:32148b5ac96b: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [13:47:18 CEST] <durandal_1707> why this guy have commit access? [13:47:42 CEST] <JEEB> o_O [13:47:59 CEST] <JEEB> that's quite... unfortunate [14:04:33 CEST] <BtbN> What even is that? Revert and immediate re-apply of the same commit, from a different author? [14:05:09 CEST] <ubitux> Author: Signed-off-by: ... [14:05:11 CEST] <ubitux> lol [14:05:22 CEST] <ubitux> wonky [14:06:59 CEST] <BtbN> It changes not a single line of code? What? Why? [14:07:33 CEST] <ubitux> it's applying 3x the "same" commit, and revert it twice [14:07:40 CEST] <ubitux> i think the patch is applied [14:09:38 CEST] <BtbN> It's Revert + Apply same patch again, twice [15:38:34 CEST] <cone-690> ffmpeg 03Jun Zhao 07master:abfeba97241e: lavf/hls: Cleanup the applehttp [21:04:11 CEST] <faLUCE> Hello. I would like to send a patch containing a new API usage example, which I think is very useful for libavcodec users. Unfortunately, adding a new example requires one new file (new_example.c), and requires to modify configure, Makefile and Makefile.example. I can create a patch with all 4 files, but if one of them change meanwhile, I have to create a new patch. I was told that a patch often has to be pinged a [21:04:13 CEST] <faLUCE> lot before it is considered/accepted, so what can I do in order to create this patch in an easy way? [21:05:39 CEST] <JEEB> if you have the commits in a branch locally then you just rebase against master. if there are actual merge conflicts git will tell you [21:05:47 CEST] <JEEB> then you just commit and finish rebase [21:06:16 CEST] <JEEB> the examples directory though isn't as much touched so not sure how likely it is that it will hit a conflict? [21:06:39 CEST] <faLUCE> JEEB: but the patch touches configure [21:07:05 CEST] <JEEB> ok, then it's more likely [21:07:19 CEST] <JEEB> but if there's no merge conflict it will just get done automagically [21:07:33 CEST] <JEEB> at the worse part you just fix a (most likely minor) merge conflict [21:07:36 CEST] <faLUCE> with rebase? [21:07:39 CEST] <JEEB> yes [21:07:51 CEST] <JEEB> you have your own xxx_example branch locally [21:07:53 CEST] <faLUCE> I see, then I have to understand how rebase works [21:07:54 CEST] <JEEB> you update your local master [21:08:19 CEST] <JEEB> faLUCE: I didn't say that there is no merge conflicts if someone changed something right next to your place and git can't figure it out by itself [21:08:29 CEST] <JEEB> in that case it will ask you which parts to keep :P [21:08:39 CEST] <JEEB> still, should be relatively quick [21:08:48 CEST] <JEEB> commit and tell rebase to --continue, done [21:09:15 CEST] <faLUCE> ok, so, I pull in local master, then I rebase my_branch (with the new example) against LOCAL master [21:09:26 CEST] <JEEB> well local or remote [21:09:29 CEST] <JEEB> either is fine [21:09:36 CEST] <JEEB> usually you just have a copy of master around locally too :P [21:09:48 CEST] <faLUCE> yes [21:09:49 CEST] <JEEB> and at least I generally update local master when I fetch [21:10:16 CEST] <faLUCE> but why is it needed a local personal branch for rebasing? [21:10:24 CEST] <faLUCE> (because I rebase all the branch?) [21:10:42 CEST] <faLUCE> (instead of specifying the files?) [21:11:11 CEST] <JEEB> well I would rather keep master clean, no? [21:11:22 CEST] <JEEB> and you are handling a patch set and thus a branch makes sense IMHO [21:11:28 CEST] <faLUCE> of course [21:11:30 CEST] <JEEB> yup [21:11:46 CEST] <JEEB> that way you can work in git, and then export patches with git format-patch when needed [21:12:07 CEST] <faLUCE> but when addind to stage the modified files, do I have to git add file1 file2 etc. each time? [21:13:08 CEST] <JEEB> in which sense? if you have a merge conflict in a single file then that's all you add? [21:13:30 CEST] <faLUCE> sorry, the question was meaningless [21:13:42 CEST] <JEEB> also I think there's a shortcut to add all currently changed but unstaged files [21:14:03 CEST] <JEEB> but the more you use something like that the more likely you are to "oh, I didn't mean to add that one to *this* commit" [21:14:06 CEST] <JEEB> :) [21:14:35 CEST] <faLUCE> yes, I'll use git add ... [21:15:06 CEST] <TheAMM> git add -u [21:15:29 CEST] <JEEB> and that I will guess is the shortcut [21:15:36 CEST] <JEEB> "unstaged", I guess? [21:15:57 CEST] <TheAMM> probably, I think it as "update" [21:16:05 CEST] <TheAMM> Adds all changes from tracked files [21:16:20 CEST] <JEEB> yea, changed but unstaged [21:16:22 CEST] <JEEB> :) [21:16:33 CEST] <JEEB> if you open up gitk or so you'll see how it calls those things [21:16:36 CEST] <JEEB> (or git status, even) [21:17:13 CEST] <TheAMM> git add -u && git commit -m "wip" && git push prod [21:17:24 CEST] <TheAMM> lifehack [21:17:56 CEST] <TheAMM> (I have some history of abusing git as a file transport on personal projects) [23:21:22 CEST] <cone-842> ffmpeg 03Marton Balint 07master:e036b8dcf46d: avdevice/decklink_dec: set configs before listing formats [23:21:23 CEST] <cone-842> ffmpeg 03Marton Balint 07master:f3e22e320142: avdevice/decklink_common: properly check DoesSupportVideoMode result when trying VANC flag [23:21:24 CEST] <cone-842> ffmpeg 03Marton Balint 07master:63c2c83f6eb4: avdevice/decklink_common: add support for DeckLink SDK 11 [23:36:26 CEST] <faLUCE> JEEB and others: I don't get a point. The devel documentation says: "When you submit your patch, please use git format-patch OR git send-email. We cannot read other diffs :-). " But from what I read, git format-patch doesn't send any email" .... is it a typo error, and "OR" should be replaced with "AND" ? [23:37:24 CEST] <nevcairiel> git send-email will do everything in one step [23:37:39 CEST] <nevcairiel> but you can also manually attach the patch as an attachment, for that use git format-patch [23:38:27 CEST] <faLUCE> I see (then the webpage should be updated with a more clear description, IMHO) [23:38:36 CEST] <JEEB> well, format-patch makes something you can attach and send. send-email does format-patch + send e-mail. so technically it could say "and send the patches as attachment" to the format-patch part, but the person writing the text probably thought the sending part was obvious [23:38:55 CEST] <faLUCE> ok, got it [00:00:00 CEST] --- Tue Apr 16 2019