libopenh264 port on Mint and more...

[medmed]

@medmed: do you have a complete example to display *.h264 in a GEM window? Would maybe help to do a quick check whether all libraries work as expected.

Here it is

A quick & Dirty H264 for Atari (32bits ARGB needed for now) based on Atari AES skeleton found on git
https://github.com/ggnkua/Atari_ST_Sour ... n/apskel.c
PS: No event management i.e. you have to wait the end of the video - cut 10s with ffmpeg for testing


You have to change the path name in the code & that's it.
There is the makefile with it - Just make & done.

To extract H264 sample from mp4 you have to use ffmpeg

Code: Select all

ffmpeg -i source_MP4_file.mp4 -vcodec copy -bsf h264_mp4toannexb -an -f h264 dest_H264_file

To downscale resolution (here 480p)

Code: Select all

ffmpeg -i source_h264_file -vf scale=852:480 dest_H264_file

[ThorstenOtto]

Many thanks! That worked rather flawlessly. Of course i couldn't resist, and did a few cleanups

• I've added a few lines so you can pass the filename to display on the command line
• for simplicity, you do only a single vro_cpyfm without looking at the rectangle list. That is of course ok, but you have to set the clipping atleast to the window area, otherwise the image will be drawn all over the desktop.
• The setup of the dest MFDB was a bit broken, but somehow worked nevertheless.
• I had to remove the printf at the end of the loop, otherwise if you start it from the console, scrolling the console window takes more time than the actual decoding...
• Added a simple printf at the end to report the FPS.

I also wonder whether using libyuv::I420ToARGB wouldn't be faster than using libyuv::I420ToRAW, and then converting it to ARGB.

And what irritates me a bit: although the scaled down image is 852x480, i get a message from H264:

Code: Select all

H264 trace 4 [OpenH264] this = 0x0x14f0ab4, Info:DecodeFrameConstruction(): will output first frame of new sequence, 864 x 480, crop_left:0, crop_right:6, crop_top:0, crop_bottom:0, ignored error packet:0.

Could it be that H264 already does some roundup to a multiple of 16 pixels internally?

And a question: is it possible that the size of the frames changes? Because you get the width&height after decoding every frame, but allocate the buffers only once.

With the example, i get 18 FPS with the original 720p image, and 27 FPS with the downscaled 480p image.

[medmed]

I've added a few lines so you can pass the filename to display on the command line
for simplicity, you do only a single vro_cpyfm without looking at the rectangle list. That is of course ok, but you have to set the clipping atleast to the window area, otherwise the image will be drawn all over the desktop.
The setup of the dest MFDB was a bit broken, but somehow worked nevertheless.
I had to remove the printf at the end of the loop, otherwise if you start it from the console, scrolling the console window takes more time than the actual decoding...
Added a simple printf at the end to report the FPS.

Many thanks Otto, it will be easier to share & test with it.

You're right the first version was really "quick & dirty" thanks for the improvements
Can you tell me for MFDB what i'm doing wrong?

I also wonder whether using libyuv::I420ToARGB wouldn't be faster than using libyuv::I420ToRAW, and then converting it to ARGB.

May be - I'll give it a try.

Could it be that H264 already does some roundup to a multiple of 16 pixels internally?

I've checked the lib code and it seems yes for my quick understanding but not sure
https://github.com/cisco/openh264/blob/ ... r_core.cpp

Code: Select all

  const int32_t kiWidth = pCurDq->iMbWidth << 4;
  const int32_t kiHeight = pCurDq->iMbHeight << 4;
  const int32_t kiTotalNumMbInCurLayer = pCurDq->iMbWidth * pCurDq->iMbHeight;
  ...
      if (pCtx->iTotalNumMbRec == kiTotalNumMbInCurLayer) {
  ...
      WelsLog (& (pCtx->sLogCtx), WELS_LOG_INFO,
               "DecodeFrameConstruction(): will output first frame of new sequence, %d x %d, crop_left:%d, crop_right:%d, crop_top:%d, crop_bottom:%d, ignored error packet:%d.",
               kiWidth, kiHeight, pCtx->sFrameCrop.iLeftOffset, pCtx->sFrameCrop.iRightOffset, pCtx->sFrameCrop.iTopOffset,
               pCtx->sFrameCrop.iBottomOffset, pCtx->iIgnoredErrorInfoPacketCount);
  

And a question: is it possible that the size of the frames changes? Because you get the width&height after decoding every frame, but allocate the buffers only once.

I think yes because imagine video recorded from mobile swapping from portrait to landscape mode...

I'm actually stuck to finding some solution to let the "for loop" running in background in order to allow window resizing, slide scroll, menu select, etc.... as the video is playing. I've searched & tried pthread or mt_shel_write without success. Aniplay let you move and scroll the video window but as there no source code available for it I've no idea about the tricky way to follow...

Does anyone know how to go about it?

[ThorstenOtto]

Can you tell me for MFDB what i'm doing wrong?

In this lines:

Code: Select all

                /* Destination MFDB Buffer */
                win_xy[4] = xwork; win_xy[5] = ywork; win_xy[6] = xwork + st_wi_mfdb.fd_w - 1; win_xy[7] = st_wi_mfdb.fd_h + hwork - 1;

win_xy[7] is set to a wrong value, it should be ywork + st_wi_mfdb.fd_h - 1 (unless the VDI supports image scaling, but fVDI doesn't, and you have use a different mode then)

I've checked the lib code and it seems yes for my quick understanding but not sure

Yes, i'm also not sure. Would be nice however to find a solution that decodes right into the wanted format, any frame (in the scaled down example) is about 1.3MB, and avoiding just a single copy of the data could drastically improve performance.

I think yes because imagine video recorded from mobile swapping from portrait to landscape mode...

For the example that might be no problem, but for the general case you then have to reallocate the buffer (maybe by checking against the previous values to avoid that).

I'm actually stuck to finding some solution to let the "for loop" running in background

I'm also currently experimenting with the code below. Theoretically it should work, but actually does not as expected. I think part of the problem is the non-preemptive nature of the pth library, actually only one thread is running at any given time, and scheduling of another thread takes only place if it calls one of the pthread_* functions. That has the effect that when you call evnt_multi(), your decoding thread won't run until the call to evnt_multi() returns. Adding MU_TIMER helps, but then framerate drops to about 8 FPS.

Another approach would be to rewrite the decoding loop to only decode a single frame, and only call it for the MU_TIMER case.

[medmed]

Can you tell me for MFDB what i'm doing wrong?

In this lines:

Code: Select all

                /* Destination MFDB Buffer */
                win_xy[4] = xwork; win_xy[5] = ywork; win_xy[6] = xwork + st_wi_mfdb.fd_w - 1; win_xy[7] = st_wi_mfdb.fd_h + hwork - 1;

win_xy[7] is set to a wrong value, it should be ywork + st_wi_mfdb.fd_h - 1 (unless the VDI supports image scaling, but fVDI doesn't, and you have use a different mode then)

I've checked the lib code and it seems yes for my quick understanding but not sure

Yes, i'm also not sure. Would be nice however to find a solution that decodes right into the wanted format, any frame (in the scaled down example) is about 1.3MB, and avoiding just a single copy of the data could drastically improve performance.

I think yes because imagine video recorded from mobile swapping from portrait to landscape mode...

For the example that might be no problem, but for the general case you then have to reallocate the buffer (maybe by checking against the previous values to avoid that).

I'm actually stuck to finding some solution to let the "for loop" running in background

I'm also currently experimenting with the code below. Theoretically it should work, but actually does not as expected. I think part of the problem is the non-preemptive nature of the pth library, actually only one thread is running at any given time, and scheduling of another thread takes only place if it calls one of the pthread_* functions. That has the effect that when you call evnt_multi(), your decoding thread won't run until the call to evnt_multi() returns. Adding MU_TIMER helps, but then framerate drops to about 8 FPS.

Another approach would be to rewrite the decoding loop to only decode a single frame, and only call it for the MU_TIMER case.

Thanks Otto.

• Window interaction works now by calling the event loop after buffer to screen without fps drop

• I've changed YUVtoRAW by YUVto24RGB but no perf increase for me

• I've removed Stride computation: very small perf increase

• The code check new size for free / malloc

• I've change log level from WELS_LOG_DEBUG to WELS_LOG_WARNING

ps: My compiler don't know "fileno" - perhaps my mintlib version also is too old...

[Eero Tamminen]

• I've changed YUVtoRAW by YUVto24RGB but no perf increase for me

Hatari profiler is pretty much made for profiling / analyzing perf for things like this: https://hatari.tuxfamily.org/doc/debugg ... #Profiling

After automating suitable test-case and its profiling with Hatari, one can easily get callgraphs with instruction and cycle count for each build.

[ThorstenOtto]

• Window interaction works now by calling the event loop after buffer to screen without fps drop

Hm, strange. It works, but i do not understand why. IMHO, it should block and do nothing after the WM_REDRAW from the initial window creation has been processed.

• I've changed YUVtoRAW by YUVto24RGB but no perf increase for me

Yes, that is IMHO the same, just with different order of channels (BGR instead of RGB). What i had in mind was to use a function that directly outputs ARGB, so the extra conversion loop in your example is not needed.

• I've removed Stride computation: very small perf increase

That has messed up display of the scaled down image, The other is still ok.

ps: My compiler don't know "fileno" - perhaps my mintlib version also is too old...

Strange. fileno() is really an old standard, i cannot imagine that this was missing in even very old mintlibs.

[medmed]

• Window interaction works now by calling the event loop after buffer to screen without fps drop

Hm, strange. It works, but i do not understand why. IMHO, it should block and do nothing after the WM_REDRAW from the initial window creation has been processed.

• I've changed YUVtoRAW by YUVto24RGB but no perf increase for me

Yes, that is IMHO the same, just with different order of channels (BGR instead of RGB). What i had in mind was to use a function that directly outputs ARGB, so the extra conversion loop in your example is not needed.

• I've removed Stride computation: very small perf increase

That has messed up display of the scaled down image, The other is still ok.

ps: My compiler don't know "fileno" - perhaps my mintlib version also is too old...

Strange. fileno() is really an old standard, i cannot imagine that this was missing in even very old mintlibs.

You're all right. Save of cpu & memory because of you
We had to replace by YUVtoBGRA and not YUVtoARGB because of Big Endian...
I'haven't noticed perf increase on my VM - Do you with this version?

[ThorstenOtto]

Hm, strange. It works, but i do not understand why. IMHO, it should block and do nothing after the WM_REDRAW from the initial window creation has been processed.

That has been clarified now. It works because
- the butdown variable is set to TRUE *after* calling st_Read_H264(). So when calling multi(), it is still FALSE, causing multi() to wait for a button release, not a button press
- the top_window variable isn't set anywhere in the sample code, so the MU_BUTTON code is never executed
- as a result, evnt_multi() continously immediately returns with a button event

However, in your real app, that situation will change i think. But you can just add MU_TIMER to the event mask, without any noticable FPS drop.

The FPS drop still occurs when i try to run the decoding loop in a thread.

I'haven't noticed perf increase on my VM - Do you with this version?

Not really. About 27-28 FPS, regardless which version.

[Eero Tamminen]

Short instructions on using Hatari profiler follow...

Setup:

• Build your optimized binary with debug symbols, in addition to optimization options (with gcc: use "-g" and do not strip the binary)
• Add build step to your Makefile to generate symbols file from the binary for post-processing: "gst2ascii your.prg > symbols.txt" (or do it manually)

Profiling:

• Run your program through Hatari GEMDOS HD emulation (= from host directory), so that Hatari can automatically load debug symbols from the binary when debugger is invoked
• Invoke Hatari debugger after your program is running, but before your program starts the part you want to measure
• Set breakpoints to start and end of the part of the program you want to analyze (add symbols for that if needed), and enable profiling with "profile on"
• When debugger is invoked on profiling end breakpoint, save the profile: "profile save profile.txt"

Profile data post-processing / viewing:

• Post-process the profile, to get overview: "hatari_profile -st -p -r symbols.txt profile.txt" (look at where cycles go, not which functions/symbols get invoked most)
• If significant part of time is spent in TOS, make sure you use e.g. EmuTOS 512k version coming with debug symbols, and provide also its symbols to the post-processor with "-a etos512k.sym" option
• Add "-g" option to post-processor run to generate callgraphs
• View the profile callgraph (for cycle counts) with: "xdot profile-2.dot" ("xdot" viewer package is available in major Linux distros)

If callgraph is too large, you can try removing most of the details with: "--emph-limit=2.0 --limit=1.0 --compact --no-leafs --no-intermediate"

If that removes too much detail, try changing "--limit" value to something smaller.

PS. Interrupt handlers mess callgraphs a bit, because they break the normal code flow. Helper functions use from everywhere in the code can make callgraphs too complex to view. Mostly it's best just to tell tell post-processor to ignore them with: "--ignore-to func1,func2,..." option.

PPS. Profiler output is only as good as your symbols data. If there are symbols missing for functions that take significant amount of time, that time gets assigned to a symbol which precedes that area of code in memory. If in doubt, check the assembly from same "profile.txt" file, to see whether there's something looking like a function entry point without a symbol (e.g. very old MiNTlib releases had symbols removed for few of the functions that took very significant amount of time).

[medmed]

Short instructions on using Hatari profiler follow...
...

Thanks you very much Eero, I've clipboard your instructions for other parts.

For performance reading H264 files if you read the code you'll see that we're only using libraries functions - The main solution to increase FPS would be to patch with asm the source code of external libraries I guess.

[medmed]

Hm, strange. It works, but i do not understand why. IMHO, it should block and do nothing after the WM_REDRAW from the initial window creation has been processed.

That has been clarified now. It works because
- the butdown variable is set to TRUE *after* calling st_Read_H264(). So when calling multi(), it is still FALSE, causing multi() to wait for a button release, not a button press
- the top_window variable isn't set anywhere in the sample code, so the MU_BUTTON code is never executed
- as a result, evnt_multi() continously immediately returns with a button event

However, in your real app, that situation will change i think. But you can just add MU_TIMER to the event mask, without any noticable FPS drop.

The FPS drop still occurs when i try to run the decoding loop in a thread.

I'haven't noticed perf increase on my VM - Do you with this version?

Not really. About 27-28 FPS, regardless which version.

Thanks Otto.

All events are fully managed in my app.
Video is playing in background of the other windows without crushing them, close, move, resize are ok.

_st_Read_H264 is called from the main event_loop who is waiting the return - I guess MU_TIMER would not let me open other files in my app during video playing. To handle this i've to execute a second event_loop with the life time of the video. I didn't noticed any FPS difference between one or two event_loop.

I'll managed the issue with no drops directly in the read function as follow :

Code: Select all

      
      		/*
      		* Old process - buffer to screen crush front windows 
      		*/          
                // st_Set_Mouse( FALSE );
                // win_refresh_from_buffer(this_win);
                // st_Set_Mouse( TRUE );
                // frame_counter++;
                // event_loop(NULL);
                
                /*
                * New process - All good 
                */   
                _INT16 top_win_handle;
                wind_get(0, WF_TOP, &top_win_handle, 0, 0, 0);
                st_Set_Mouse( FALSE );
                if(top_win_handle != this_win_handle)
                {       
                    GRECT rect;
                    wind_update(BEG_UPDATE);
                    wind_get(this_win_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h);
                    while(rect.g_h  != 0 && rect.g_w != 0){
                        if ( rc_intersect(&this_win->work_area, &rect) ){
                            wipe_rect_area(&rect);
                            if(this_win->wi_mfdb.fd_addr != NULL){
                                buffer_to_screen(this_win->wi_handle, &rect);
                            }
                        }
                        wind_get( this_win_handle ,WF_NEXTXYWH ,&rect.g_x , &rect.g_y, &rect.g_w, &rect.g_h );
                    }
                    wind_update(END_UPDATE);
                } else {
                    win_refresh_from_buffer(this_win);
                }
                st_Set_Mouse( TRUE );
                frame_counter++;
                event_loop(NULL);

[medmed]

For now i'm trying to play wav sound on Atari / Aranym : I'm reading codes from MxPlay & GemJing to understand how to proceed... and why 2 buffers or TimerA etc...

[OL]

Code: Select all

      
      		/*
      		* Old process - buffer to screen crush front windows 
      		*/          
                // st_Set_Mouse( FALSE );
                // win_refresh_from_buffer(this_win);
                // st_Set_Mouse( TRUE );
                // frame_counter++;
                // event_loop(NULL);
                
                /*
                * New process - All good 
                */   
                _INT16 top_win_handle;
                wind_get(0, WF_TOP, &top_win_handle, 0, 0, 0);
                st_Set_Mouse( FALSE );
                if(top_win_handle != this_win_handle)
                {       
                    GRECT rect;
                    wind_update(BEG_UPDATE);
                    wind_get(this_win_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h);
                    while(rect.g_h  != 0 && rect.g_w != 0){
                        if ( rc_intersect(&this_win->work_area, &rect) ){
                            wipe_rect_area(&rect);
                            if(this_win->wi_mfdb.fd_addr != NULL){
                                buffer_to_screen(this_win->wi_handle, &rect);
                            }
                        }
                        wind_get( this_win_handle ,WF_NEXTXYWH ,&rect.g_x , &rect.g_y, &rect.g_w, &rect.g_h );
                    }
                    wind_update(END_UPDATE);
                } else {
                    win_refresh_from_buffer(this_win);
                }
                st_Set_Mouse( TRUE );
                frame_counter++;
                event_loop(NULL);

- As I understand, you can remove st_Set_Mouse() because as your window always update content draw above it will have near no impact on the screen, so can be removed, this is 2 instruction less
- In theory wind_update() should be done before wind_get(0, WF_TOP, &top_win_handle, 0, 0, 0); status could change between this call and next one
- I know it simplify process to look at top window, but my point of view, it is better to not take into account in some case AES can return your application as top but it is not real top so remove wind_get(0, WF_TOP....) and test
- You can add test after wind_get(this_win_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h); if w and h return correspond to width and height of your window work area, the loop after can be skip.

Olivier

[OL]

I'm also currently experimenting with the code below. Theoretically it should work, but actually does not as expected. I think part of the problem is the non-preemptive nature of the pth library, actually only one thread is running at any given time, and scheduling of another thread takes only place if it calls one of the pthread_* functions. That has the effect that when you call evnt_multi(), your decoding thread won't run until the call to evnt_multi() returns. Adding MU_TIMER helps, but then framerate drops to about 8 FPS.

Another approach would be to rewrite the decoding loop to only decode a single frame, and only call it for the MU_TIMER case.

The best is to create a real thread, you can do it with shel_write() problem with this, it work only under Magic and MyAES, but if not work should return an error so one thread like can still be used but in this case this is difficult to do calculation and manage interface in same time, thread simplify situation, simple if calculation thread is able redraw itself window, I was thinking MyAES not allowed get information from a thread that not create itself the window but surprizing this is not the case (don't know for Magic) so you can create window with event thread and check window rectangle with calculation thread, an other option is to send message to event thread manager but it will be slower and use timer in evnt_multi() is not good idea for system load. This is interesting case, should not be difficult to do.

Olivier

[OL]

Error

[ThorstenOtto]

I guess MU_TIMER would not let me open other files in my app during video playing. To handle this i've to execute a second event_loop with the life time of the video. I didn't noticed any FPS difference between one or two event_loop.

MU_TIMER is absolutely needed in your example. If you change the

Code: Select all

evnt_multi(MU_MESAG | MU_BUTTON | MU_KEYBOARD, 1, 1, butdown, ....

to

Code: Select all

evnt_multi(MU_MESAG | MU_BUTTON | MU_KEYBOARD, 1, 1, 1, ....

then your decode loop will stop when calling multi() the 2nd time. It works once for the first frame, because you get a WM_REDRAW from the wind_open(), but then will block because there are no other messages.

[ThorstenOtto]

Btw, i found that the openh264 libraries on my site were missing the 020 and v4e libraries. If you need them, just refetch the archive; nothing else has changed.

And atached my current version of the example program. You can experiment with it setting USE_THREADS to 1. The archive also contains a port of this to X11; when i set limit_fps = 0 there, i get around ~260 FPS. So the 27 from aranym is not that bad

One thing i want to try is to use libavcodec instead of openh264. I think it should also be able to decode the files, just have figure out how to invoke it.

[medmed]

Btw, i found that the openh264 libraries on my site were missing the 020 and v4e libraries. If you need them, just refetch the archive; nothing else has changed.

And atached my current version of the example program. You can experiment with it setting USE_THREADS to 1. The archive also contains a port of this to X11; when i set limit_fps = 0 there, i get around ~260 FPS. So the 27 from aranym is not that bad

One thing i want to try is to use libavcodec instead of openh264. I think it should also be able to decode the files, just have figure out how to invoke it.

Thanks Olivier, Thanks Otto.

Really well done Otto! I have code to read (and above all your pthread implementation)

For avcodec I'm afraid about an eventual hight number of dependencies but I've don't really check for now...

I've tried to implement autoscale and Olivier advises in the code in attachment and in my app code:
In my app code everything is ok but in the test script we use vsclip alway clip at x = 0 & y = 0 and I don't understand why as I try to debug this from hours now.... Perhaps You or Olivier have idea about this issue?
I've implemented libyuv::I420Scale who scale following the size of the window.

[medmed]

Btw, i found that the openh264 libraries on my site were missing the 020 and v4e libraries. If you need them, just refetch the archive; nothing else has changed.

And atached my current version of the example program. You can experiment with it setting USE_THREADS to 1. The archive also contains a port of this to X11; when i set limit_fps = 0 there, i get around ~260 FPS. So the 27 from aranym is not that bad

One thing i want to try is to use libavcodec instead of openh264. I think it should also be able to decode the files, just have figure out how to invoke it.

Thanks Olivier, Thanks Otto.

Really well done Otto! I have code to read (and above all your pthread implementation)

For avcodec I'm afraid about an eventual hight number of dependencies but I've don't really check for now...

I've tried to implement autoscale and Olivier advises in the code in attachment and in my app code:
In my app code everything is ok but in the test script we use vsclip alway clip at x = 0 & y = 0 and I don't understand why as I try to debug this from hours now.... Perhaps You or Olivier have idea about this issue?
I've implemented libyuv::I420Scale who scale following the size of the window.

It's ok - I found my mistake: I passed bad array to vscopy...

BTW in patch attached below improved with automatic scaling down & up + background video playing (no crushing)
Two define :
- LIMIT UP SCALE to stay below the original size (set to FALSE in the build)
- RESPECT_VIDEO_RATIO to force ratio between width & height (set to FALSE in the build)

PS : We note that FPS increse when scaling down - I'm thinking that the bottleneck come from vscopy
Perhaps someone can test with nvdi if performances are better as I'm on fVdi...?

And atached my current version of the example program. You can experiment with it setting USE_THREADS to 1. The archive also contains a port of this to X11; when i set limit_fps = 0 there, i get around ~260 FPS. So the 27 from aranym is not that bad

Plus your binary is 30% smaller than this one - perhaps the cpu arg to gcc? I'll give a try.

Btw, i found that the openh264 libraries on my site were missing the 020 and v4e libraries. If you need them, just refetch the archive; nothing else has changed.

Thanks Otto - For now all my tests are done with 68000 builds / But it's true it'll be better to change that.

Perhaps someone with a firebee and cgi could do some perf tests I'm curious

[OL]

Btw, i found that the openh264 libraries on my site were missing the 020 and v4e libraries. If you need them, just refetch the archive; nothing else has changed.

And atached my current version of the example program. You can experiment with it setting USE_THREADS to 1. The archive also contains a port of this to X11; when i set limit_fps = 0 there, i get around ~260 FPS. So the 27 from aranym is not that bad

One thing i want to try is to use libavcodec instead of openh264. I think it should also be able to decode the files, just have figure out how to invoke it.

Thanks Olivier, Thanks Otto.

Really well done Otto! I have code to read (and above all your pthread implementation)

For avcodec I'm afraid about an eventual hight number of dependencies but I've don't really check for now...

I've tried to implement autoscale and Olivier advises in the code in attachment and in my app code:
In my app code everything is ok but in the test script we use vsclip alway clip at x = 0 & y = 0 and I don't understand why as I try to debug this from hours now.... Perhaps You or Olivier have idea about this issue?
I've implemented libyuv::I420Scale who scale following the size of the window.

Sorry I not understand your question about vs_clip(), regarding your code I not understand why you want do vs_clip, it is not need at any time, I not understand you use vr_recfl() as just after you erase anything draw with vro_cpyfm(). You call vsf_interior() before each redraw set one is enough and in this case if vr_recfl is remove it is not need.
I don't know why you need the first rc_intersect() AES return always return a rectangle inside the working area so you have not to do intersect with working area

Your code

Code: Select all

rect.g_h = 0; rect.g_w = 0; rect.g_x = 0; rect.g_y = 0;

				wind_update(BEG_UPDATE);
                wind_get(wi_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h);
                // if(rect.g_h != 0 && rect.g_w != 0){
					while(rect.g_h  != 0 && rect.g_w != 0){
						if ( rc_intersect((GRECT*)&win_xy[4], &rect) ){
							rect_pxy[0] = rect.g_x;
							rect_pxy[1] = rect.g_y;
							rect_pxy[2] = rect.g_x + rect.g_w - 1;
							rect_pxy[3] = rect.g_y + rect.g_h - 1;
							printf("2 - x %d y %d\n", xwork, ywork);
							vsf_interior(handle, 0);
							set_clip(1, rect.g_x, rect.g_y, rect.g_w, rect.g_h);
							vr_recfl(handle, rect_pxy);
							vro_cpyfm(handle, S_ONLY, rect_pxy, &st_wi_mfdb, &screen_mfdb);
							set_clip(0, rect.g_x, rect.g_y, rect.g_w, rect.g_h);
						}
						wind_get( wi_handle ,WF_NEXTXYWH ,&rect.g_x , &rect.g_y, &rect.g_w, &rect.g_h );
					}
					printf("out\n");
                // } else {
				// 	printf("x %d y %d\n", xwork, ywork);
				// 	vsf_interior(handle, 0);
				// 	set_clip(1, xwork, ywork, wwork, hwork);
				// 	vr_recfl(handle, win_xy);
				// 	vro_cpyfm(handle, S_ONLY, win_xy, &st_wi_mfdb, &screen_mfdb);
				// 	set_clip(0, xwork, ywork, wwork, hwork);
                // }
                wind_update(END_UPDATE);

				show_mouse();

Should be something like this:

Code: Select all

		rect.g_w = 0; rect.g_h = 0; 
		wind_update(BEG_UPDATE);
                wind_get(wi_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h);
              
		while(rect.g_h  != 0 && rect.g_w != 0){
						
			rect_pxy[0] = rect.g_x;
			rect_pxy[1] = rect.g_y;
			rect_pxy[2] = rect.g_x + rect.g_w - 1;
			rect_pxy[3] = rect.g_y + rect.g_h - 1;
							
			vro_cpyfm(handle, S_ONLY, rect_pxy, &st_wi_mfdb, &screen_mfdb);
			
			if((rect.g_w!=st_wi_mfdb.fd_w) || (rect.g_h!=st_wi_mfdb.fd_h))
						wind_get( wi_handle ,WF_NEXTXYWH ,&rect.g_x , &rect.g_y, &rect.g_w, &rect.g_h );
			else rect.g_h=0;
		}

                wind_update(END_UPDATE);

Sorry I can't experiment anything for the moment, I'm far from my Atari system

Olivier

[medmed]

Btw, i found that the openh264 libraries on my site were missing the 020 and v4e libraries. If you need them, just refetch the archive; nothing else has changed.

And atached my current version of the example program. You can experiment with it setting USE_THREADS to 1. The archive also contains a port of this to X11; when i set limit_fps = 0 there, i get around ~260 FPS. So the 27 from aranym is not that bad

One thing i want to try is to use libavcodec instead of openh264. I think it should also be able to decode the files, just have figure out how to invoke it.

Thanks Olivier, Thanks Otto.

Really well done Otto! I have code to read (and above all your pthread implementation)

For avcodec I'm afraid about an eventual hight number of dependencies but I've don't really check for now...

I've tried to implement autoscale and Olivier advises in the code in attachment and in my app code:
In my app code everything is ok but in the test script we use vsclip alway clip at x = 0 & y = 0 and I don't understand why as I try to debug this from hours now.... Perhaps You or Olivier have idea about this issue?
I've implemented libyuv::I420Scale who scale following the size of the window.

Sorry I not understand your question about vs_clip(), regarding your code I not understand why you want do vs_clip, it is not need at any time, I not understand you use vr_recfl() as just after you erase anything draw with vro_cpyfm(). You call vsf_interior() before each redraw set one is enough and in this case if vr_recfl is remove it is not need.
I don't know why you need the first rc_intersect() AES return always return a rectangle inside the working area so you have not to do intersect with working area

Your code

Code: Select all

rect.g_h = 0; rect.g_w = 0; rect.g_x = 0; rect.g_y = 0;

				wind_update(BEG_UPDATE);
                wind_get(wi_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h);
                // if(rect.g_h != 0 && rect.g_w != 0){
					while(rect.g_h  != 0 && rect.g_w != 0){
						if ( rc_intersect((GRECT*)&win_xy[4], &rect) ){
							rect_pxy[0] = rect.g_x;
							rect_pxy[1] = rect.g_y;
							rect_pxy[2] = rect.g_x + rect.g_w - 1;
							rect_pxy[3] = rect.g_y + rect.g_h - 1;
							printf("2 - x %d y %d\n", xwork, ywork);
							vsf_interior(handle, 0);
							set_clip(1, rect.g_x, rect.g_y, rect.g_w, rect.g_h);
							vr_recfl(handle, rect_pxy);
							vro_cpyfm(handle, S_ONLY, rect_pxy, &st_wi_mfdb, &screen_mfdb);
							set_clip(0, rect.g_x, rect.g_y, rect.g_w, rect.g_h);
						}
						wind_get( wi_handle ,WF_NEXTXYWH ,&rect.g_x , &rect.g_y, &rect.g_w, &rect.g_h );
					}
					printf("out\n");
                // } else {
				// 	printf("x %d y %d\n", xwork, ywork);
				// 	vsf_interior(handle, 0);
				// 	set_clip(1, xwork, ywork, wwork, hwork);
				// 	vr_recfl(handle, win_xy);
				// 	vro_cpyfm(handle, S_ONLY, win_xy, &st_wi_mfdb, &screen_mfdb);
				// 	set_clip(0, xwork, ywork, wwork, hwork);
                // }
                wind_update(END_UPDATE);

				show_mouse();

Should be something like this:

Code: Select all

		rect.g_w = 0; rect.g_h = 0; 
		wind_update(BEG_UPDATE);
                wind_get(wi_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h);
              
		while(rect.g_h  != 0 && rect.g_w != 0){
						
			rect_pxy[0] = rect.g_x;
			rect_pxy[1] = rect.g_y;
			rect_pxy[2] = rect.g_x + rect.g_w - 1;
			rect_pxy[3] = rect.g_y + rect.g_h - 1;
							
			vro_cpyfm(handle, S_ONLY, rect_pxy, &st_wi_mfdb, &screen_mfdb);
			
			if((rect.g_w!=st_wi_mfdb.fd_w) || (rect.g_h!=st_wi_mfdb.fd_h))
						wind_get( wi_handle ,WF_NEXTXYWH ,&rect.g_x , &rect.g_y, &rect.g_w, &rect.g_h );
			else rect.g_h=0;
		}

                wind_update(END_UPDATE);

Sorry I can't experiment anything for the moment, I'm far from my Atari system

Olivier

Thanks you very much Olivier.
I'm still learning AES: I confused vsclip with vro_cpyfm in my questions - Sorry, My bad.
You're alright and I've replaced

Code: Select all

	
wind_update(BEG_UPDATE);
wind_get(wi_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h);
while(rect.g_h  != 0 && rect.g_w != 0){
	if ( rc_intersect((GRECT*)&win_xy[4], &rect) ){
		vsf_interior(handle, 0);
		set_clip(1, rect.g_x, rect.g_y, rect.g_w, rect.g_h);
		vr_recfl(handle, rect_pxy);
		vro_cpyfm(handle, S_ONLY, win_xy, &st_wi_mfdb, &screen_mfdb);
		set_clip(0, rect.g_x, rect.g_y, rect.g_w, rect.g_h);
	}
wind_get( wi_handle ,WF_NEXTXYWH ,&rect.g_x , &rect.g_y, &rect.g_w, &rect.g_h );
}
wind_update(END_UPDATE);

By this one and it's all good

Code: Select all

rect.g_w = 0; rect.g_h = 0; 
wind_update(BEG_UPDATE);
wind_get(wi_handle, WF_FIRSTXYWH, &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h);
while(rect.g_h  != 0 && rect.g_w != 0){
	set_clip(1, rect.g_x, rect.g_y, rect.g_w, rect.g_h);
	vro_cpyfm(handle, S_ONLY, win_xy, &st_wi_mfdb, &screen_mfdb);
	
	if((rect.g_w!=st_wi_mfdb.fd_w) || (rect.g_h!=st_wi_mfdb.fd_h))
				wind_get( wi_handle ,WF_NEXTXYWH ,&rect.g_x , &rect.g_y, &rect.g_w, &rect.g_h );
	else rect.g_h=0;
}
wind_update(END_UPDATE);

Many thanks Olivier.

My first error was the array passed to vro_cpyfm -

[medmed]

@Olivier I have to re-add the wipe screen stuff :

Sorry I not understand your question about vs_clip(), regarding your code I not understand why you want do vs_clip, it is not need at any time

Because it's needed to move windows in front of the video one who was playing - without this vro_cpyfm crush the front window..

I not understand you use vr_recfl() as just after you erase anything draw with vro_cpyfm(). You call vsf_interior() before each redraw set one is enough and in this case if vr_recfl is remove it is not need.

Because if I don't and if the video was not setup to scale automatically I've a transparent window...(see screenshots attached below)

[medmed]

But I've optimized the loop because of you.

Many thanks.

[ThorstenOtto]

Plus your binary is 30% smaller than this one - perhaps the cpu arg to gcc? I'll give a try.

That's mainly because i stripped binary. Even without that, its a little bit smaller than yours, but that is maybe because you have slightly different versions of mintlib +libm