Leaderboard

Small example to access Github's contributions of a given user and display them using TeeChart. https://github.com/Steema/TeeChart-VCL-GitHub-Contributions This demo is made with VCL but almost identical code works in Firemonkey.

First of all, thanks. I'll be back as soon as I understand better what the analysis is showing, and then I might be able to do the "little code changes" you mention :). Just keep in mind, that the sinkwriter isn't giving you any control over dts, pts., or how video and audio are interleaved. Renate

Your issues are now fixed in SVN and will be zipped overnight. The GET and DELETE methods now support REST PContBodyJson, PContBodyUrlEn and PContBodyXML content types, beware web servers may not support this. The ICS web server also now supports body content with GET and DELETE requests, provided there are UrlJHandlers for these methods or the application handles the content stream. The TRestParams component has a new RParamFmt property that for Json only defines whether nested objects or an array should be formatted, default is RPFmtNestObj (Nested Objects, same as previously), or RPFmtArrayVal (Array of Values) if first element is any array, or RPFmtArrayObj (Array of Objects) where each element is treated as object in the array. Note RPFmtArrayObj allows duplicate names in Add methods, since output into different objects. For instance: RPFmtNestObj: {"field1":"data1","field2":"data2","field3":[data1, data2, data3]} RPFmtArrayVal: [data1, data2, data3] RPFmtArrayObj: [{"field":"data1"},{"field":"data2"},{"field":[data1, data2, data3]}] Angus

Great, and you are on the right way, make use of real video for testing. You are right and i am right here, but you are ignoring one essential fact, that your daily player as mine are good, they are so good that they fix this stuff at runtime to their best effort, i provided earlier a link to ffmpeg and how it does its magic to fix these to its best effort. As for proof, i will provide one, but let me make it clear here, your player not showing the problem is solemnly based on their advanced algorithm for corrections, BUT and it is huge but, if you are you use similar code with basic algorithms and APIs just like yours the problem will manifest badly. now to the proof; 1) i went to this page https://archive.org/details/4-k-hdr-60-fps-dolby-vision-demo-2160p-60fps-vp-9-128kbit-aac and didn't download the video with highest quality, i used the "H.264" on the right side under "Download Options" it is 16.6mb , that is enough. 2) I have ffprobe (the link to download is in earlier post) and extracted the frames and their timing for debugging the video its self and see how original with quality encoder have interleaved the frames and their duration. 3) i transcoded the video without changing the default setting and repeated the process with output video and restoring the FPS to 60 instead of 30, the downloaded/original video is 59.94 fps 4) used the ffprobe on these 3 video files 5) made small parser for the ffprobe output, here is its parsing loop, it is easier to see and follow than using Notepad++ procedure TForm10.ProcessFile(const FileN: string); var StrList: TStringList; Line: string; i, p: Integer; begin StrList := TStringList.Create; try StrList.LineBreak := '[/FRAME]'#13#10; StrList.LoadFromFile(FileN); if StrList.Count = 0 then Exit; Memo1.Lines.BeginUpdate; try for i := 0 to StrList.Count - 1 do begin Line := StrList[i]; p := PosEx('pkt_pos', Line); if p > 0 then Line := LeftStr(Line, p - 1); if Length(Line) > Length('[FRAME] media_type=') then Line := RightStr(Line, Length(Line) - Length('[FRAME] media_type=') - 1); Line := ReplaceStr(Line, #13#10, ' '); Memo1.Lines.Add(Line); end; finally Memo1.Lines.EndUpdate; end; finally StrList.Free; end; end; Now i went to compare and check for the timestamps 1) the original (downloaded) some of the begging and middle and end of that original video, how commercial (or may be even not commercial) and high end encoder interleaved the frames and their durations What we see, smooth interleave with fixed frames length, but it compensate with extra video when it is short, and extra audio frame when it is short, notice the audio and video end at the same, the green box show at the end the difference is small, yet after that it will push both streams to the end but the difference through out all video didn't go above this 10-13 ms, 2) Lets see the transcoded version at 30 fps (default setting) and from the middle We see a desyncing in the middle the last video frame in the video sequence is 99.133333 while the following audio sections of frames, the last one corresponding to that video frame is 99.118271 the difference is 15ms at the end the difference is 33ms, so we correct and synced video now is desynced and audio is drifting by something 10-11ms per minutes, not much , i agree and in fact it is almost within the allowed standard for 10ms drift, but again this small drifting is for this combination for this video. 3) lets see the one i transcoded further from the generated 60 fps into 60fps and the result , taking only the first frames and the last Now it is more synced at the end than the first transcoded one, the drift is only 6ms ! How this happen ? Just look at how the first frames and their time stamps, the audio start at "pts=2229 pts_time=0.046437" meaning the audio is drifted forward 46ms since the the start and lost 40ms till the end. Dear Renate, in no way i am saying it is bad or wrong, pointing to anything, and pretty please don't take my posts here in the wrong way, you did awesome job and pretty neat usage MF, i merely want to show you a better way, make it commercial worth and avoid these hidden bugs, my points here are for anyone who love to know, or care. Now, is it huge adjustment, no you are overthinking it, it is the small details, like when the audio frames should be pushed and interleaved?, how many of these streams and frames of sort before switching to another? do we need to make sure of the duration in dynamic way instead of simple loops? All of these questions are very simple and the change in your code should be minimum, again not asking you to change it, just to point when it fail if it failed beyond acceptable video quality, the culprit was the fixed frames count and duration, and that is it. Debugging (in this case dissecting) the video itself to its frames while keeping an eye on how best practice is being utilized is way better then watching video as player play their roles, and not being sure of using best practice or accurate timing. To summarize what could be better; 1) push less frames before switching between streams like shown above, like you LOTR video, 1or 2 then switch instead of pushing over 8, 2) make sure the the audio frames start form 0 time 3) if you don't like adjusting video duration, it is ok, we have many ways to skin a cat, don't know what the cat did but follow best practice and the cat will be skinned, adjust audio frames, even this is not really necessary, and both can be skipped, and not touched 4) third way to fix 3, we use the most naive way, and make sure there is no drifting skipping (3) , just make audio frames try to hit the video duration or more, if it did hit more even with 1ms then the next chunk of audio push less frames and skip an audio frame, because we are pushing at 1 video frame then 1 audio frame, then it is easy as skip this time. and we fixed synced video. Anyway, that is all and good luck, it is your code and it is your call.

In OpenSSL, SSL 3.0 and TLS 1.x share some common code during the handshake, so you may see references to SSL3 when TLS is actually being used. Nor should you, except when you have very specific security requirements. If you don't set a CipherList explicitly, a default one is used, which should usually be suitable for most tasks. HOWEVER, do note that in July 2018 (between D10.2 and D10.3), there was a behavior change made in Indy. Maybe that is contributing to your issue? Prior to the change (ie, in the Indy bundled with XE7), if the CipherList was empty then Indy used a hard-coded cipher list that was taken from the OpenSSL SDK: 'AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH' After the change, Indy no longer uses that. It now lets OpenSSL use whatever default cipher list it was compiled with. If IsTLSv1_2Available() returns False, that means the OpenSSL DLLs you are using do not export the TLSv1_2_method(), TLSv1_2_server_method() and, TLSv1_2_client_method() functions. I can assure you that the OpenSSL 1.0.2 DLLs in Indy's GitHub repo DO export those functions. Note, if Indy doesn't detect TLS 1.1 and TLS 1.2 are available, it will silently fallback to TLS 1.0. That might also be contributing to your issue. Just to check, what does Indy's OpenSSLVersion() function report for you after the DLLs are loaded? I would also suggest using SysInternals Process Explorer to view your app's process at runtime and verify that your app is actually loading the expected OpenSSL DLLs and not some other incompatible OpenSSL DLLs that may be located elsewhere on your PC.

"Not thread-safe" in this case doesn't mean crash and burn. It just means that if one thread modifies the global FormatSettings then it will affect all other threads also using it. Hardly a problem - even if you did output floating point values in the exception message.

I updated the report https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-3711

InnoSetup