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

[burek]

[00:24:58 CEST] <another> Thomas_J: add -v debug
[01:30:51 CEST] <Thomas_J> -v debug is to verbose. It overruns my terminal. Too many lines of output. I will try to dump it to a file tomorrow.
[01:33:57 CEST] <steve___> Thomas_J: use { command | command; } &> filename   ## assuming you're using bash
[01:34:55 CEST] <cehoyos> Thomas_J: First step to solve your issue is to test current FFmpeg instead of an eight-months old version
[02:01:20 CEST] <furq> Thomas_J: just use -report
[02:01:28 CEST] <furq> that saves the debug log to a file
[02:19:46 CEST] <Thomas_J> <cehoyos> This is a version that was suggested to me yesterday by JEEB. Previously I was testing against new compilations of the latest stable version. They all had the same results.
[02:32:03 CEST] <cehoyos> All I can tell you is that the old version has more bugs and less features, I have no idea why it would be recommended.
[06:00:02 CEST] <MomokoGC> hello
[06:00:23 CEST] <MomokoGC> i am trying to set a metadata tag called "ARTIST"
[06:00:33 CEST] <MomokoGC> i do this -metadata ARTIST="%artist%"
[06:01:00 CEST] <MomokoGC> but then somehow ffmpeg changes the tag from "ARTIST" to "Performer"
[06:01:17 CEST] <MomokoGC> is there anyway i can get it to use the tag "ARTIST" only?
[06:02:06 CEST] <MomokoGC> it's also changing "TITLE" to "Track name" :(
[06:52:13 CEST] <MomokoGC> nvm i found another cli tool called tag to do it
[12:37:27 CEST] <SoItBegins> I have an AVI file that has a VERY unusual video format. The format appears to be WRAW - a sequence of uncompressed .BMP images, I think? - and FFMPEG doesnt know how to handle it. Is there a way I can override FFMPEGs codec autodetection and get this video into a format that a modern video editor can read?
[12:41:10 CEST] <durandal_1707> SoItBegins: try: ffmpeg -c:v bmp -i input.avi -f null -
[12:42:23 CEST] <SoItBegins> Well, it didnt give me an error about not recognizing the codec, though it did say, Could not find codec parameters for stream 0 (Video: bmp, none, 256x192, 12609 kb/s): unspecified pixel format.
[12:42:46 CEST] <SoItBegins> And then it stopped because, Too many packets buffered for output stream 0:1., which was the videos audio track.
[12:42:53 CEST] <SoItBegins> (The audio track is plain old uncompressed audio.)
[12:52:06 CEST] <SoItBegins> durandal_1707: Now how can I copy the video over to a new output file without FFMPEG recompressing it?
[12:52:54 CEST] <dv_> hm I have an openmax based vp8 encoder here, and with it, you explicitely define whether or not the next frame shall be an alternate reference frame, golden frame, and whether or not that frame should be used for prediction
[12:53:04 CEST] <dv_> my problem is - I have no idea when to enable these things
[12:53:20 CEST] <dv_> I have no low-level encoding experience with vp8
[12:53:40 CEST] <dv_> is this even common? I thought typically people let libvpx decide when a golden frame and altref frames are generated
[12:54:17 CEST] <JEEB> yes, generally the encoder has proper logic for frame type selection. it's nice if the API lets you override, but there should be a default
[12:54:52 CEST] <JEEB> if it requires you to do all the heavy lifting then a) that's fun b) sounds like "we did not care too much about this"
[12:55:48 CEST] <dv_> it starts at page 6 https://www.khronos.org/registry/OpenMAX-IL/extensions/KHR/OpenMAX_IL_1_1_2_Extension%20VP8%20WebP.pdf
[12:55:51 CEST] <durandal_1707> SoItBegins: please provide sample file if you can
[12:56:11 CEST] <dv_> I suppose one way to go is to try to copy the logic that's in libvpx for this
[12:56:26 CEST] <SoItBegins> durandal_1707: Uploading, hang on a minute
[12:56:30 CEST] <durandal_1707> SoItBegins: you can copy but if it is not supported, it will still not work
[12:57:11 CEST] <SoItBegins> durandal_1707: I was worried you might say something like that. In that case, my goal is to get the file from point A to point B with the least compression possible.
[13:00:22 CEST] <durandal_1707> SoItBegins: ok, but first we need to make sure that it can be decoded
[13:00:51 CEST] <SoItBegins> Well, I can open it with Quicktime Player, so its not garbage. The question then falls to, can ffmpeg decode it.
[13:02:14 CEST] <durandal_1707> only if you provide actual file, without samples ffmpeg will never support it
[13:02:44 CEST] <SoItBegins> Only 30 seconds to go on the upload.
[13:02:59 CEST] <SoItBegins> Might not be BMP. FFMPEG gave error bad magic number'.
[13:04:17 CEST] <SoItBegins> durandal_1707: Heres file: https://mega.nz/#!pY1WnQhC!eW3f2MzyAN4Pu4BDzPjCN7K9SVmY6szxuNWnD-3mnxs
[13:05:34 CEST] <SoItBegins> Note that I might have to go to bed soon&
[13:06:03 CEST] <SoItBegins> VLC, by the way, says the video is 32 bits RGB (RV32)
[13:07:03 CEST] <durandal_1707> still downloading
[13:09:47 CEST] <durandal_1707> SoItBegins: this is not BMP, it is just raw video
[13:09:58 CEST] <durandal_1707> uncompessed
[13:10:18 CEST] <SoItBegins> [nod] Im not surprised. This was converted from a kind of obscure video game format to AVI
[13:10:34 CEST] <SoItBegins> What do I tell FFMPEG for video reading purposes? Can I convert it to .dv?
[13:10:43 CEST] <durandal_1707> so make sure your ffmpeg is not too old
[13:11:01 CEST] <durandal_1707> Stream #0:0: Video: rawvideo, bgra, 256x192, 12609 kb/s, 8 fps, 8 tbr, 8 tbn, 8 tbc
[13:11:22 CEST] <SoItBegins> ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers
[13:11:22 CEST] <SoItBegins>   built with Apple LLVM version 9.0.0 (clang-900.0.39.2)
[13:11:58 CEST] <SoItBegins> I tried ffmpeg -f rawvideo -i testopa2.avi testconv.mp4 but it gave me:
[13:12:04 CEST] <SoItBegins> [IMGUTILS @ 0x7fff52e40208] Picture size 0x0 is invalid
[13:12:55 CEST] <durandal_1707> SoItBegins: ffmpeg -i testopa2.avi testconv.mp4
[13:13:21 CEST] <durandal_1707> you should not override format like that
[13:13:23 CEST] <SoItBegins> . . . . . . . . . . . . . . . now why didnt I try that to begin with?
[13:14:18 CEST] <SoItBegins> durandal_1707: Littttle problem. Audio came through. Video didn't.
[13:14:52 CEST] <SoItBegins> Its all black.
[13:14:53 CEST] <durandal_1707> SoItBegins: use proper player and not quicktime
[13:15:07 CEST] <durandal_1707> it is because its encoded as yuv444
[13:15:22 CEST] <SoItBegins> Ah. Well, see, the thing is, VLC can read it, but Im trying to import it into Camtasia
[13:15:24 CEST] <durandal_1707> SoItBegins: ffmpeg -i testopa2.avi -pix_fmt yuv420p testconv.mp4
[13:15:26 CEST] <SoItBegins> for Mac
[13:15:37 CEST] <SoItBegins> Which uses the Quicktime framework to import everything so...
[13:16:42 CEST] <durandal_1707> force pix_fmt, see command above
[13:16:52 CEST] <SoItBegins> durandal_1707: It works!
[13:17:18 CEST] <SoItBegins> Last question: What video codec option will compress it as little as possible? (and still have it readable by Quicktime player and similar)
[13:17:52 CEST] <durandal_1707> lossless, like lagarith/utvideo/magicyuv
[13:18:08 CEST] <SoItBegins> All right. A big THANK YOU for all of your help!
[13:22:29 CEST] <SoItBegins> durandal_1707: PS: Turns out the way I found that appears to be lossless (and is read by Camtasia) was to set FFMPEG to output the video as a .MOV with the codec being a PNG image sequence (!).
[13:24:15 CEST] <durandal_1707> nice
[13:43:59 CEST] <dv_> JEEB: do you know if the ffmpeg vp8 vaapi & v4l2enc based encoders too have to decide manually what frames to encode as altef/golden frames?
[17:21:29 CEST] <Thomas_J> WOW! I just discovered gnutls-cli
[17:29:26 CEST] <Thomas_J> Anyone familiar with gnutls? Are the same options such as --tofu be used on the ffmpeg command line the same as they are used in gnutls-cli?
[17:45:34 CEST] <sine0> hey folks. I am trying to use ffmpeg to squash down a raw avi I got from after effects into an smaller mp4 with no audio
[17:46:02 CEST] <sine0> ffmpeg version N-93897-g8f6e651833
[17:46:31 CEST] <sine0> anyway I keep getting these stack dump type outputs
[17:46:42 CEST] <sine0> and the resulting file is grey and fux0red
[17:47:03 CEST] <sine0> [libx264 @ 000001677a5ec440] frame I:1     Avg QP:19.11  size: 44541
[17:47:03 CEST] <sine0> [libx264 @ 000001677a5ec440] frame P:63    Avg QP:19.78  size:  8567
[17:48:34 CEST] <DHE> that's just detailed encoding information. apparently your video is like 2 seconds long?
[17:49:32 CEST] <sine0> no there was more i didnt paste it though..
[17:50:12 CEST] <sine0> im just playing witht he settings I guess the question is, does a raw avi file have all the information needed to convert into another type in ffmpeg
[17:50:53 CEST] <DHE> typically. you're seeing what ffmpeg is seeing. you can try ffplay to play the original video directly - if there are inconsistencies there then ffmpeg is having problems reading the source
[17:52:18 CEST] <sine0> hmm it plays, smooth and sweet
[17:52:57 CEST] <sine0>  Stream #0:0: Video: rawvideo, bgra, 1280x720, 740240 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
[17:53:20 CEST] <sine0> ffmpeg -i comp.avi -c:v libx264 -preset fast -f mp4 woot.mp4
[17:53:28 CEST] <sine0> that should work for it amirite
[17:53:55 CEST] <sine0> it might be my build I was having problems before, its a windows nightly build..
[17:54:52 CEST] <Thomas_J> gnutls has command line options. How would I pass them to gnutls from within the ffmpeg command line through rtmps://?
[17:55:13 CEST] <sine0> im just grabbing 4.1.3 stable
[18:02:11 CEST] <DHE> sine0: depending on the player you may have an colourspace issue. try adding "-pix_fmt yuv420p" just before the output filename
[18:03:28 CEST] <sine0> I rerendered it from AAE and used a codec
[18:03:57 CEST] <sine0> DV PAL
[18:06:25 CEST] <cehoyos> There is nothing "unstable" about current FFmpeg and nothing "stable" about an FFmpeg release, releases are just old and unsupported
[18:08:39 CEST] <pink_mist> cehoyos: I'd beg to differ - at least from the point of view of writing software that is linking to ffmpeg ...
[18:08:51 CEST] <pink_mist> not from a user standpoint though
[18:12:44 CEST] <sine0> cehoyos: so nightly builds are always stable ?
[18:13:45 CEST] <cehoyos> pink_mist: If you are a distributor, you have to use the buggy, old releases. If you are a user, you don't have to.
[18:14:14 CEST] <pink_mist> I'm a distributor
[18:14:14 CEST] <cehoyos> No, not "always". But they contain less bugs than any release, and except for special circumstances, it makes no sense to even look at them
[18:14:24 CEST] <cehoyos> Is sine0 a distributor?
[18:16:10 CEST] <sine0> he is not
[18:40:56 CEST] <Thomas_J> How can I pass the option --insecure to gnutls from within the ffmpeg command line?
[18:50:28 CEST] <JEEB> Thomas_J: if you mean the certificate verification, then the gnutls TLS protocol module has a "verify" option that can be disabled. the problem is that you're then utilizing another protocol on top of that (rtmps, for example) which then has to also have that option and then pass that onto the TLS implementation
[18:53:01 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/rtmpproto.c;h=b741e421af972a66bf424c730f3992549962eb05;hb=HEAD#l3094
[18:53:04 CEST] <JEEB> doesn't seem so
[18:53:20 CEST] <JEEB> those are the options you can give the RTMP protocol
[18:55:13 CEST] <JEEB> if you are on an x86 system then patching that yourself for testing to make sure it's what it means and what you need shouldn't take too long
[18:56:06 CEST] <JEEB> and yes I just checked gnutls-cli's --insecure manpage
[18:56:21 CEST] <JEEB> it is the certificate validation, which is what the "verify" option in TLS in FFmpeg does
[19:07:12 CEST] <JEEB> hmm
[19:07:18 CEST] <JEEB> why doesn't https have to do it...
[19:07:27 CEST] Action: JEEB goes read how API clients disable certificate checks
[19:08:36 CEST] <JEEB> Thomas_J: huh, I have no means of testing this but try setting -tls_verify 1
[19:09:02 CEST] <JEEB> if you need it for input, put it before input. if you need it for output, put it after input and before output
[19:12:34 CEST] <JEEB> right. it does pass opts as-is to the lower protocol
[19:12:42 CEST] <JEEB> in both HTTP(S) and RTMP
[19:15:09 CEST] <Thomas_J> JEEB> the fact that gnutls id hiding behind rtmps is the reason I asked. I discovered gnutls-cli and looking at connecting to Facebook. The Facebook domain has certs but when I probe the full URL of the facebook connection, it doesn't authenticate.
[19:16:10 CEST] <Thomas_J> What I am looking for is to be able to try some of the gnutls options from within my ffmpeg string.
[19:16:14 CEST] <JEEB> see what I have written, last 7 or so lines should get you the gist :P
[19:16:39 CEST] <Thomas_J> Thanks.
[19:17:51 CEST] <Thomas_J> "-tls_verify 1" Where will I place this? befor -f flv?
[19:18:13 CEST] <JEEB> I commented on the positioning, what matters is before/after input :P
[19:18:27 CEST] <JEEB> since all options will be kept pushed to all the modules utilized specifically by ffmpeg.c
[19:18:34 CEST] <JEEB> until one of them accepts it
[19:19:26 CEST] <JEEB> Thomas_J: also for insecure  you probably want 0 there
[19:19:27 CEST] <JEEB> not 1
[19:19:28 CEST] <JEEB> :P
[19:19:39 CEST] <JEEB> if your logs show that the TLS certificate check is what is failing
[19:21:52 CEST] <Thomas_J> Thanks, I'll try it now. Is there documentation on the gnutls options?
[19:22:15 CEST] <JEEB> there's a common list of options for the TLS stuff
[19:22:24 CEST] <JEEB> I have linekd it in the chat if you scroll up a bit
[19:22:28 CEST] <JEEB> it's the git link
[19:23:00 CEST] <JEEB> also, if your log level is debug or more (-v debug or more) it should show stuff like "Unable to verify peer certificate"
[19:23:04 CEST] <JEEB> if you think that is your issue
[19:23:23 CEST] <JEEB> I can link you all the logging the gnutls module does if it fails to verify
[19:23:57 CEST] <JEEB> starting from this line there's the av_log lines http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/tls_gnutls.c;h=f32bc2821b8e48290a17513f1ce7a69ba22beac6;hb=HEAD#l193
[19:24:01 CEST] <Thomas_J> Thanks. Forgive my rudamentry questions but I can't break the mindset of the order of things is command followed by options and flags.
[19:24:18 CEST] <JEEB> and those are actually on the error log level
[19:24:26 CEST] <JEEB> so you should have seen those messages if the certificate check was your issue
[19:24:31 CEST] <JEEB> even without a high log level
[19:24:36 CEST] <JEEB> (since they are errors, d'uh)
[19:24:56 CEST] <JEEB> if you do not see them, then that is not your issue
[19:25:36 CEST] <JEEB> if you have a log available from f.ex. -v verbose level or higher, people here can help check it if paired with your command line :P (you can clear stuff like RTMP credentials etc from it)
[19:25:37 CEST] <Thomas_J> Ran that. To verbose. Yes but now that I now it's a cert problem, I have to go farther. That's where I am delighted to find gnutls-cli.
[19:25:55 CEST] <JEEB> Thomas_J: do you actually *know* that is the case?
[19:26:01 CEST] <JEEB> do you see those errors I just linked
[19:26:03 CEST] <JEEB> in your output
[19:26:20 CEST] <JEEB> they should have been always pushed out unless you specifically make ffmpeg.c silent so that it doesn't even log errors
[19:26:30 CEST] <JEEB> stuff like "Unable to verify peer certificate
[19:27:52 CEST] <Thomas_J> No but at least gnutls gives me a way to further probe down into my suspicions.
[19:28:10 CEST] <JEEB> if you do not see that error then stop doing assumptions, PLEASE
[19:28:26 CEST] <JEEB> FFmpeg does log TLS verification issues
[19:28:29 CEST] <JEEB> as *errors*
[19:28:40 CEST] <JEEB> if you do not see those, it either doesn't get that far, or something else
[19:29:02 CEST] <Thomas_J> I have seen the error. That is why I think that this rabbit is worth chasing.
[19:29:34 CEST] <JEEB> Thomas_J: ok, so you have seen TLS verification errors from *FFmpeg* ?
[19:29:46 CEST] <JEEB> please verify this so you can be helped the best way possible
[19:31:02 CEST] <JEEB> also I just verified with `ffmpeg -h full |grep "tls_verify"` that the default is 0
[19:31:04 CEST] <Thomas_J> Absolutely. The last time I ran a -v debug, plain as day it said TLS: bla-bla-bla.
[19:31:05 CEST] <JEEB> for tls_verify
[19:31:41 CEST] <JEEB> yes, it will say TLS something or another at that level of verbosity
[19:31:45 CEST] <JEEB> but that is not necessarily an error
[19:32:23 CEST] <JEEB> I just do not want you to do wild goose chaces any more than necessary
[19:32:58 CEST] <JEEB> you can use -v verbose as your standard and provide a log of a failed attempt
[19:33:33 CEST] <Thomas_J> I'm going to get back to digging through the Docs now, In the immortal words of A.S., I'll be back. Or did Mcarther say that?
[19:34:11 CEST] <Thomas_J> He said I shall return, That's it.
[19:40:19 CEST] <another> Just for the record: How to debug: 1) Get logs. 2) Read the error messages. Don't just skim them, read them carefully. Start at the top; everything further down could be subsequent errors.
[19:44:52 CEST] <JEEB> and 3) if you cannot see any clear indications of anything, post the log on a pastebin site and link it here
[19:46:17 CEST] <another> i was goinng for a more general approach
[21:28:11 CEST] <Thomas_J> What does "Unknown dref type 0x206c7275 size 12" mean?
[21:40:56 CEST] <JEEB> Thomas_J: a mp4/mov reference type
[21:41:09 CEST] <JEEB> I don't think that is a fatal message sine it's on debug level
[21:41:26 CEST] <JEEB> it just mentions that "btw the data also contained this, but I didn't know what to do with it"
[21:45:09 CEST] <JEEB> seems to be " lru" which the other way round is "url "
[21:45:10 CEST] <Thomas_J> I just triesd another live stream. The console out is this;
[21:45:18 CEST] <Thomas_J> [tcp @ 0x3599b60] Successfully connected to 157.240.2.3 port 443
[21:45:18 CEST] <Thomas_J> [rtmps @ 0x3599830] Cannot open connection tls://live-api-s.facebook.com:443
[21:45:18 CEST] <Thomas_J> rtmps://live-api-s.facebook.com:443/rtmp/2373322142735510?s_bl=1&s_ps=1&s_sml=0&s_sw=0&s_vt=api-s&a=AbxqwyoT1iqQLCcV: Resource temporarily unavailable
[21:45:18 CEST] <Thomas_J> [AVIOContext @ 0x3599c70] Statistics: 200636 bytes read, 2 seeks
[21:46:14 CEST] <JEEB> port 443 sounds like it's not RTMPS but rather RTMP over HTTPS or something?
[21:46:21 CEST] <JEEB> not that I know what facebook does
[21:46:23 CEST] <Thomas_J> facebook is waiting for my stream.
[21:46:41 CEST] <JEEB> ok, sorry
[21:46:46 CEST] <JEEB> rtmps default port is indeed 443
[21:47:05 CEST] <JEEB> (I just saw RTMPS_DEFAULT_PORT being defined as 443)
[21:47:21 CEST] <Thomas_J> Port 443 is imap tls port. I have no idea why facebook uses that .
[21:47:54 CEST] <JEEB> it's just the HTTPS port :)
[21:48:40 CEST] <JEEB> anyways, with that you've posted at least some logs :P
[21:48:46 CEST] <Thomas_J> Facebook dropped the use of rtmp on May 1st.
[21:48:52 CEST] <JEEB> I *know*
[21:49:13 CEST] <JEEB> mostly because I happen to share a chat room with one of the Facebook streaming people
[21:49:30 CEST] <JEEB> (note: that doesn't mean I know /anything/ about Facebook RTMP)
[21:49:31 CEST] <Thomas_J> The rest is just spam going to the console.
[21:49:42 CEST] <JEEB> you should be OK with just -v verbose in general
[21:50:15 CEST] <JEEB> also next time for multiple lines utilize a pastebin kind of site. any works that is not dumb and can be linked to
[21:51:08 CEST] <JEEB> anyways, that shows that opening the underlying protocol failed
[21:51:14 CEST] <Thomas_J> Could you do me a favor? could you ask your friend if he is using ffmpeg to stream to Facebook now and if so HOW?
[21:51:26 CEST] <JEEB> that person is not my friend
[21:52:05 CEST] <Thomas_J> I did not feel comfortable posting my key to a pastebin.
[21:52:14 CEST] <JEEB> yes, you can hide stuff like that
[21:52:29 CEST] <JEEB> the main part is to just get the general command line and terminal output
[21:53:36 CEST] <Thomas_J> At this point, I feal the inclusion could be pertinant to troubleshooting why a tls handshake cannot be made.
[21:54:25 CEST] <JEEB> hmm
[21:55:03 CEST] <Thomas_J> I am using gnutls as a client. Could it still be expecting a secret key from me?
[21:55:31 CEST] <JEEB> is the gnutls client doing HTTPS or just TLS against the server?
[21:55:49 CEST] <JEEB> also if you have on a x86_64 machine built FFmpeg yourself, there is a function that you could attempt to make more verbose
[21:55:56 CEST] <JEEB> print_tls_error in libavformat/tls_gnutls.c
[21:56:06 CEST] <JEEB> it right now only prints out stuff under specific circuimstances
[21:56:19 CEST] <JEEB> and unless you filtered something out there were no internal messages from the TLS implementation coming out
[21:56:25 CEST] <Thomas_J> Only being used with ffmpeg.
[21:56:39 CEST] <JEEB> you have lost me with that response
[21:59:05 CEST] <Thomas_J> As far as I know, I am only using gnutls from within ffmpeg for streaming to Facebook.
[21:59:45 CEST] <JEEB> ok, and here I thought you had probed FB's end point with the gnutls command line app and were referring to that :P
[21:59:50 CEST] <Thomas_J> I believe that it is a module that I compiled.
[21:59:52 CEST] <JEEB> sorry, I expected too much out of this
[22:01:31 CEST] <Thomas_J> I have probed Facebook with gnotls-cli which I installed separately using apt install.
[22:03:29 CEST] <MoziM> hello
[22:06:41 CEST] <Thomas_J> Hellloooooo
[22:07:27 CEST] <JEEB> Thomas_J: anyways if you have built FFmpeg against gnutls and yourself, then http://up-cat.net/p/a9492457
[22:07:44 CEST] <JEEB> should make it speak a bit more if it fails in a place where print_tls_error gets called :P
[22:07:58 CEST] <JEEB> since the log you posted did not contain any gnutls error logging.
[22:08:33 CEST] <Thomas_J> Actually, I am now using the pre-built bin that you suggested 2 days ago with gnutls enabled.
[22:08:40 CEST] <JEEB> ok, too bad then :P
[22:08:58 CEST] <JEEB> it was good for basic testing but you are not suddenly going to get more logging out of it
[22:09:22 CEST] <JEEB> maybe try running it under strace? have you been able to connect and handhshake with the gnutls command line application against FB's server?
[22:10:15 CEST] <Thomas_J> I haven't tried gnutls from the command line.
[22:10:36 CEST] <JEEB> but you just noted > I have probed Facebook with gnutls-cli
[22:11:58 CEST] <JEEB> I think, unfortunately, that I'm giving up on you for the day :P it's eleven in the night, and I want to test some things.
[22:13:34 CEST] <Thomas_J> The apt installed gnutls-cli is different than the compiled version of gnutls that ffmpeg is linking to.(I think) I know it links to it because the final error is coming from TLS.
[22:14:19 CEST] <Thomas_J> When I try gnutls from the command line, it is not in bashes path.
[22:14:19 CEST] <JEEB> that message you posted just notes that the connection in general failed
[22:14:43 CEST] <JEEB> the connection did happen to be the TLS connection utilized by RTMPS, yes
[22:15:08 CEST] <JEEB> but it gives literally zero hints about what failed :P
[22:15:36 CEST] <Thomas_J> That time it just failed to connect but when facebook is not set waiting, I get an error message from TLS:
[22:16:31 CEST] <JEEB> also
[22:16:39 CEST] <JEEB> that resource temporarily unavailable
[22:16:44 CEST] <JEEB> is EAGAIN
[22:16:53 CEST] <JEEB> aka "please try again". does it actually fail after that?
[22:19:21 CEST] <JEEB> if it does it might not be handling EAGAIN during open
[22:21:55 CEST] <JEEB> it would be really nice if you can provide the full -v verbose or -v debug log with the credentials hidden in a pastebin or whatever when you have a proper FB publishing point available and you're trying to push to it
[22:22:18 CEST] <JEEB> I just want to see the whole shebang because at this point I don't know how I can interpret some things you say
[22:26:49 CEST] <Thomas_J> Okay, now I am lost. Trying so many different variances of the command line, I'm at a loss as to how to duplicate the command that made TLS show it's face on the error out.
[22:27:50 CEST] <Thomas_J> But I have seen it on occasion so I know it is linked with ffmpeg.
[22:30:25 CEST] <Thomas_J> If I leave off the Facebook key at the end of the URI then ffmpeg just sits there waiting for more input. With the complete URL, then ffmpeg completes and ends with the 10 mile long spam to the console and the final ending outputs.
[22:32:28 CEST] <Thomas_J> I still think that it is something that I am missing for the setup of gnutls that keeps it from completing a handshake with FB..
[22:38:00 CEST] <Thomas_J> https://pastebin.com/rCPFwGwU/?e=1
[22:42:14 CEST] <Thomas_J> Sorry, that pastebin url is NG. Use: https://pastebin.com/rCPFwGwU
[22:44:47 CEST] <Thomas_J> This is the commant string that made TLD report; https://pastebin.com/hDxZPTmP
[22:45:54 CEST] <Thomas_J> That's the command string that made TLS report.
[22:46:20 CEST] <JEEB> > 4.1.3
[22:46:26 CEST] <JEEB> can you try the master build
[22:46:32 CEST] <Thomas_J> My mind says one thing while my flying fingers go somewhere else.
[22:46:32 CEST] <JEEB> should be available from the same place
[22:46:46 CEST] <JEEB> I think I specifically mentioned using master
[22:46:54 CEST] <JEEB> back when linking the build
[22:47:38 CEST] <JEEB> because there was a fix that I pushed into master but nobody told which releases they wanted the fix into :P
[22:47:44 CEST] <Thomas_J> If that's a bin it has to run in an ARM processor.
[22:48:00 CEST] <JEEB> https://www.johnvansickle.com/ffmpeg/
[22:48:06 CEST] <JEEB> like, literally the goddamn same site
[22:48:10 CEST] <JEEB> just the left one instead of the right one
[22:48:19 CEST] <JEEB> not release but git master :P
[22:49:04 CEST] <Thomas_J> 4.1.4 is now current.
[22:50:01 CEST] <JEEB> take the master
[22:50:04 CEST] <JEEB> not 4.1.4
[22:50:06 CEST] <JEEB> not release
[22:50:11 CEST] <JEEB> just take the git master
[22:53:26 CEST] <Thomas_J> There is nothing I can see on this page that says master. They are all bin builds for different environments.
[22:54:49 CEST] <JEEB> the "git" one is git master
[22:54:52 CEST] <JEEB> from that date
[22:55:08 CEST] <JEEB> yes I dislike the fact that the page actually doesn't say "git master"
[22:55:25 CEST] <JEEB> although the description on that same page mentions it
[22:55:26 CEST] <JEEB> > Note: it's highly recommended to use git master builds, because bug fixes and other improvements are added daily.
[22:55:35 CEST] <Thomas_J> You suggested I try the armhf build. That's what I am working with now.
[22:55:46 CEST] <JEEB> you picked the right one
[22:55:49 CEST] <JEEB> see the left side
[22:55:52 CEST] <JEEB> for christ's sake
[22:55:58 CEST] <JEEB> it has armhf for *both*
[22:59:02 CEST] <Thomas_J> OHHH... I didn't relate when it said git master builds are preferred but didn't realize it meant the static builds below. I thought it was advising to get the source from Github.
[22:59:38 CEST] <Thomas_J> My bad.
[23:05:47 CEST] <Thomas_J> Well! a whole new bunch of error messages. Looks promisig. I'll Pastebin
[23:06:27 CEST] <JEEB> yes because now that your log contained the actual version - it was a version without the fix that I applied for gnutls connectivity :P
[23:06:49 CEST] <JEEB> I was working under the assumption that since I said "git master" you would have been using the git build
[23:06:59 CEST] <JEEB> and thus I was working under the assumption that whatever failed it was not that
[23:09:02 CEST] <Thomas_J> https://pastebin.com/hjJwrgVh
[23:10:07 CEST] <Thomas_J> I didn't realize that they were 2 columns one for git build and the other side for a NOT get build.
[23:10:36 CEST] <JEEB> congrats, you have attained an actual RTMP connection but facebook is now telling you that you are lacking an identifier
[23:11:42 CEST] <Thomas_J> SEE! I told you that it looks promising. :)
[23:11:56 CEST] <JEEB> and that whole message after "Server error:" comes from FB
[23:12:05 CEST] <JEEB> so it's not FFmpeg message but 100% FB
[23:12:31 CEST] <Thomas_J> GREAT.I think I can work with that.
[23:13:15 CEST] <JEEB> I will attempt to ask the person doing the releases which branches are supposed to still be supported
[23:13:26 CEST] <JEEB> because I kind of want to apply that gnutls fix elsewhere as well :P
[23:13:34 CEST] <Thomas_J> Why is there non-git builds on that page that don't work wright?
[23:14:06 CEST] <JEEB> no, I don't really care about those builds. I just want to know which branches are still within some sort of support and thus I'll stick the fix there :P
[23:14:23 CEST] <JEEB> the people creating binaries will eventually make binaries out of newer releases as well
[23:14:26 CEST] <JEEB> :P
[23:15:48 CEST] <Thomas_J> The problem is, that there are some of us that are old and our eyes aren't what they should be and we don't know the difference anyway and get trapped with builds that should have been taken down.
[23:16:26 CEST] <JEEB> well the thing is, as I noted nobody replied to my requests on info regarding which branches (releases) are still updated :P
[23:16:33 CEST] <JEEB> -> the fix is only in master right now
[23:16:37 CEST] <JEEB> and in the upcoming 4.2 release
[23:16:49 CEST] <JEEB> (since new releases get branched off of master)
[23:21:19 CEST] <Thomas_J> I see. But, John VanSickle really should take those bad builds down.
[23:21:29 CEST] <JEEB> they're not bad
[23:21:38 CEST] <Thomas_J> they are a real trap.
[23:21:39 CEST] <JEEB> they're just what's within that release at this moment
[23:22:12 CEST] <JEEB> as far as I know pretty much the only TLS server which hit that gnutls API usage issue was indeed Facebook
[23:22:36 CEST] <JEEB> but anyways, yes. I will attempt to figure out which branches to back-port the fix to :P
[23:22:44 CEST] <Thomas_J> But he already put up the newest Git builds and then updated them to v4.1.4.
[23:22:59 CEST] <JEEB> they are two separate things
[23:23:05 CEST] <kepstin> the 'git master' builds are code that isn't yet available in a release
[23:23:09 CEST] <kepstin> and 4.1 is a different branch
[23:23:14 CEST] <JEEB> he has one set of master builds, and one set of the latest release branch :P
[23:23:16 CEST] <Yuyu0> there is even a recommendation on the page itself to use the git master builds
[23:23:38 CEST] <JEEB> anyways, it's a bug - it's fixed - nobody told me where to backport it to :P
[23:24:00 CEST] <JEEB> I could have gone for 4.1 only but I'd rather figure out all "currently supported" things
[23:24:09 CEST] <JEEB> whatever that means
[23:24:18 CEST] <Thomas_J> I see. Then he is only updating the releases as they come through without knowing of the trmp problem.
[23:24:24 CEST] <kepstin> I'd assume "everything that hasn't been moved to old releases on https://www.ffmpeg.org/download.html" is probably a good start
[23:25:40 CEST] <Thomas_J> Well, I am really glad that we (you) found the problem that I have been butting my head against.
[23:40:43 CEST] <Thomas_J> As I type, I now have a live stream running on my Facegbook wall! Thank you, Thank you, Thank you, all.
[23:42:03 CEST] <Thomas_J> Almost 2 months of effort and perseverance beyond human trial.
[00:00:00 CEST] --- Wed Jul 10 2019