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

[burek]

[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