TRichView.com

Hi all,

I'm testing the new RVMedia v7.1 ffmpeg demo project setting the "RVCamera.Latency = 0".

If I run three instances of the program connecting three differents local network cameras, they work fine, it is, the image on all the programs are more or less synchronized along the time.

But, if I setup the three cameras in one single instance of the program, the playback starts unsynchronized and finally are completely worst, slow and with a big delay between each camera.

So, summaryzing, the v7.1 is not better than v6 or v7 in RTSP multiple network camera situation.

Is there any other think I can change?

Thanks,

Visually, I cannot reproduce this problem.
I'll make a test showing camera FPS.

If you use several cameras pointing to the same dynamic image like:
a) a move,
b) road traffic,
c) never end looping image.
it is easy to see how gradually the multiview's playback of each camera slowdown until the image jumps but still far away to be synchronized.

I created a test project:
https://www.trichview.com/support/files/CamTest3.zip

It opens the specified URL in 3 cameras. For each camera, it displays the count of received frames per second, and the count of drawn frames per second. Numbers are updated each 3 seconds (so 3 seconds averages are shown).

For any case, I included a compiled EXE and FFmpeg DLLs.
In this demo, I left Latency unchanged.

In my test, I cannot notice that numbers are decreased after time. They can be decreased sometimes (if there is an unstable connection), but then they become larger than normal. For your traffic camera samples, 15 FPS is usually kept on my computer.

Hi Sergey and panlab_mf,

I downloaded your CamTest3 and compiled it with v6.1.1
And here is my findings:
1) Using ScaleMM and enabling optimize, the 3 cams become synchronized as shown in the attached image, while in your compiled exe there is variance.
2) Your exe always have one cam delaying the most and it is mostly cam1 (top right) as shown in the image, in fact the screenshot i took after 15 minute of running both EXE's yours and mine at the same time, and cam1 is showing images from 17 second ago
3) leaving them running around 25 minutes, now i see all 6 cams show the same images.
4) The second image is for the threads and context switching, here clearly ScaleMM helping 3 background threads become faster 3 times, while the other three threads gained less advantage.

Hope this help and save your time.

Regards
https://ibb.co/wh6ZwFy

Kas wrote: ↑Mon Nov 18, 2019 8:28 pm Hi Sergey and panlab_mf,

I downloaded your CamTest3 and compiled it with v6.1.1
And here is my findings:
1) Using ScaleMM and enabling optimize, the 3 cams become synchronized as shown in the attached image, while in your compiled exe there is variance.
2) Your exe always have one cam delaying the most and it is mostly cam1 (top right) as shown in the image, in fact the screenshot i took after 15 minute of running both EXE's yours and mine at the same time, and cam1 is showing images from 17 second ago
3) leaving them running around 25 minutes, now i see all 6 cams show the same images.
4) The second image is for the threads and context switching, here clearly ScaleMM helping 3 background threads become faster 3 times, while the other three threads gained less advantage.

Hope this help and save your time.

Regards
https://ibb.co/wh6ZwFy

Hi Kas,

Thanks for your effort to reproduce my issue. That's exaclty what I mean, the playback of the three cameras pass to be "live broadcast" (less than a second) to become "deferred retransmission" (more that 5 seconds).

I'm going to modify the original ffmpeg demo project to be able to show the FPS as the testcam3 does. But I don't know how to activate the scaleMM. Can you tell me how to do that?

Edit1: Ok, now I know ScaleMM is a Memory Manager replacement. I use to use EurekaLog for that, but only during the development phase.

Thanks,

Hello Sergey,

Your test seems to work, but it is not the issue I'm dealing with. Can you try three local different cameras using the same instance of the program? For instance, you can setup several rtsp servers using the ffmpeg tool and test with it.

Can you please do a new test and tell me why your component is not able to playback multi-different-local-camera without suffering the effect of lethargy in the playback speed of video streaming?

I've recorded a desktop capture video that shows up what I mean.

Thanks,

Hi panlab_mf, and thank you.

Download the latest and stable ScaleMM2 from here https://github.com/andremussche/scalemm

I use EurekaLog my self, and please note EurekaLog will cause any benchmark result to be very inconsistent, so make sure EurekaLog is disabled when testing for speed or profiling, because the result might make no sense, any other case feel free to enable it,
and one more thing :don't use EL memory manager in any case other than debugging or bug hunting because it is way too slow, specially in such case when you need the minimum of delay of receiving over Internet and decoding.

The strange thing with Sergey EXE is cam1 delayed and then start to delayed more reaching may be 20 second after 15-20 minutes, then suddenly around 25 minutes the 3 cams start to show the same frame !

Regards,

We will try to change thread priorities and to reduce count of memory allocations/deallocations.
Some time is needed for testing...

Hi Sergey,

I tested few things with profiler, but first i want to say, i don't want to waste your time because i might be wrong, in that case i am sorry, and it is your call after all, and i know i am not covered with support as my license expired and i didn't update yet, but my findings might help you and save you time.

ScaleMM is better than FastMM in one thing, it reduce threads contention, and according to the profiler there is huge time wasted on waiting on those critical section, so i googled for FFMpeg thread safety and all what i could find is discussion about initializing and finalizing the encoder/decoder or registering a codec that those are not thread safe,
some of the resources i found :
https://ffmpeg.org/pipermail/libav-user ... 07298.html
https://stackoverflow.com/questions/153 ... ading-safe


so logically this means all other functions are thread safe, right ?

I commented (removed)
glCriticalSection.SafeEnter;
//glCriticalSection.Release;

from those functions in MRVFFMPEGObject
function TRVMFFMPEG.InitDecode(const filename: PAnsiChar) : boolean;
function TRVMFFMPEG.PlayDecode : boolean;
function TRVMFFMPEG.DeinitDecode : boolean;

now the result with the stock memory manager is astonishing, the 3 cams start together in very short time (relatively) and closing the application takes less time too, and the most important is the 3 cams are 100% synchronized showing the same frame, i also added another (fourth) cam and there is no performance penalty at all.

Hope this help and save your time.

Best regards,
Kas

Thank you very much!
Yes, it looks like this critical section is not needed for applications that only receive video (since we already implemented av_lockmgr_register).
We need to test how this change affects recording.

Thank you Sergey,

I am glad to hear that helped.


Regards,

Fixed in version 7.1.1.