View Issue Details

IDProjectCategoryView StatusLast Update
0000660Cinelerra-GG[All Projects] Bugpublic2024-06-17 20:45
ReporterPhyllisSmith Assigned ToPhyllisSmith  
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000660: Render Farm does not respect "Render range" of Selection or In/Out pointers
DescriptionWhen rendering with the render farm enabled, if you select Project for the Render Range, the entire project is rendered as it should be. However, if you have a selection highlighted on the timeline or In/Out points set, and select that for the Render Range, it always starts at the beginning of the timeline but does end correctly instead of going all the way. Also, there is usually a dummy file for the first rendered file.

History - this was working for sure on July 29, 2016 but I have not looked into where it broke yet. I noticed that the Release Notes date back to June 2016 so it should be somewhat easy to find when changes were made that might have affected this. Just a guess is that it has to do with changes made to "start" for Batch Rendering as I vaguely remember a complaint about this because it started at the location of the cursor instead of the beginning of the timeline.
TagsNo tags attached.

Activities

PhyllisSmith

PhyllisSmith

2024-06-17 20:45

manager   ~0005682

@Andrew-R
@Andrea_Paz
This fix has been checked into GIT and Andrey will be automatically building the 5 newer operating systems with this patch in. Or if anyone else wants to try it, it is included in the chromakeyhsv/avid test appimage.
   https://cinelerra-gg.org/download/testing/cin-x86_64_replaced_chromakeyhsv.AppImage
Andrea_Paz

Andrea_Paz

2024-06-17 09:12

manager   ~0005681

I also tested project, selection and In/Out points. Everything works very well. Good patch!
Andrew-R

Andrew-R

2024-06-17 04:38

reporter   ~0005680

@PhyllisSmith - I think testing if renderfarm still respect video/audio checkboxes in rendering dialog, and also work from command line willbe good idea ....
PhyllisSmith

PhyllisSmith

2024-06-16 22:36

manager   ~0005679

Last edited: 2024-06-16 22:38

View 2 revisions

Note from @Andrew-R:
"another idea

replace new body of function (all lines after first { until last } )

PackagingEngineDefault::get_package_single_farm

modified in

https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blobdiff;f=cinelerra-5.1/cinelerra/packagingengine.C;h=222f8d30c260baef686d0325e0351a090c081255;hp=778d4e6e9772a7510e3d9f55dc20dad1af2305bd;hb=94fc059e6ed3f77f20531338cbb03bdb3b4d9eab;hpb=15411d7912d8aa1b9bea6ba8862517b058861771

with old (before this commit) body function ..."

The above note from Andrew worked perfectly for this old, old bug from 2019 -- surprising that it was just found now.
@Andrea_Paz -- could you test the attached patch so I have verification and can check it into GIT? Use:
   patch -p0 < renderfarm.patch (from your cinelerra-5.1 directory)
I tested project, selection, In/Out points, and single frame and all seemed to work.



renderfarm.patch (5,352 bytes)
--- cinelerra/packagingengine.C
+++ cinelerra/packagingengine.C
@@ -89,71 +89,94 @@
 RenderPackage* PackagingEngineDefault::get_package_single_farm(double frames_per_second,
 		int client_number, int use_local_rate)
 {
-	RenderPackage *result = 0;
-	float avg_frames_per_second = preferences->get_avg_rate(use_local_rate);
-	double length = package_len;
-	int scaled_length = 0;
-
-	if( (default_asset->audio_data &&
-		(audio_position < audio_end && !EQUIV(audio_position, audio_end))) ||
-	    (default_asset->video_data &&
-		(video_position < video_end && !EQUIV(video_position, video_end))) ) {
+
+//printf("PackageDispatcher::get_package %ld %ld %ld %ld\n", audio_position, video_position, audio_end, video_end);
+
+		RenderPackage *result = 0;
+		float avg_frames_per_second = preferences->get_avg_rate(use_local_rate);
+
+		if(audio_position < audio_end ||
+			video_position < video_end)
+		{
 // Last package
-		result = packages[current_package];
-		result->audio_start = audio_position;
-		result->video_start = video_position;
-		result->video_do = default_asset->video_data;
-		result->audio_do = default_asset->audio_data;
-
-		if( current_package >= total_allocated-1 ) {
-			result->audio_end = audio_end;
-			result->video_end = video_end;
- 			audio_position = result->audio_end;
-			video_position = result->video_end;
-		}
-		else {
-			if( frames_per_second > 0 && 
-			    !EQUIV(frames_per_second, 0) && !EQUIV(avg_frames_per_second, 0) ) {
-// package size to fit the requestor.
-				length *= frames_per_second / avg_frames_per_second;
-				scaled_length = 1;
+			double scaled_len;
+			result = packages[current_package];
+			result->audio_start = audio_position;
+			result->video_start = video_position;
+			result->video_do = default_asset->video_data;
+			result->audio_do = default_asset->audio_data;
+
+			if(current_package >= total_allocated - 1)
+			{
+				result->audio_end = audio_end;
+				result->video_end = video_end;
+				audio_position = result->audio_end;
+				video_position = result->video_end;
 			}
-			if( length < min_package_len )
-				length = min_package_len;
-			double end_position = current_position + length;
-
-			if( result->video_do ) {
-				int64_t video_end = end_position * default_asset->frame_rate;
-				result->video_end = MIN(this->video_end, video_end);
-				end_position = video_end / default_asset->frame_rate;
-			}
-			if( result->audio_do ) {
-				int64_t audio_end = end_position * default_asset->sample_rate;
-				result->audio_end = MIN(this->audio_end, audio_end);
+			else
+// No useful speed data.  May get infinity for real fast jobs.
+			if(frames_per_second > 0x7fffff || frames_per_second < 0 ||
+				EQUIV(frames_per_second, 0) ||
+				EQUIV(avg_frames_per_second, 0))
+			{
+				scaled_len = MAX(package_len, min_package_len);
+
+				result->audio_end = audio_position +
+					Units::round(scaled_len * default_asset->sample_rate);
+				result->video_end = video_position +
+					Units::round(scaled_len * default_asset->frame_rate);
+
+// If we get here without any useful speed data render the whole thing.
+				if(current_package >= total_packages - 1)
+				{
+					result->audio_end = audio_end;
+					result->video_end = video_end;
+				}
+				else
+				{
+					result->audio_end = MIN(audio_end, result->audio_end);
+					result->video_end = MIN(video_end, result->video_end);
+				}
+
+				audio_position = result->audio_end;
+				video_position = result->video_end;
 			}
-			audio_position = result->audio_end;
-			video_position = result->video_end;
-			current_position = end_position;
+			else
+// Useful speed data and future packages exist.  Scale the
+// package size to fit the requestor.
+			{
+				scaled_len = package_len *
+					frames_per_second /
+					avg_frames_per_second;
+				scaled_len = MAX(scaled_len, min_package_len);
+
+				result->audio_end = result->audio_start +
+					Units::to_int64(scaled_len * default_asset->sample_rate);
+				result->video_end = result->video_start +
+					Units::to_int64(scaled_len * default_asset->frame_rate);
+
+				result->audio_end = MIN(audio_end, result->audio_end);
+				result->video_end = MIN(video_end, result->video_end);
+
+				audio_position = result->audio_end;
+				video_position = result->video_end;
 
 // Package size is no longer touched between total_packages and total_allocated
-			if( scaled_length && current_package < total_packages-1 ) {
-				double remaining =
-					result->audio_do ? (double)(audio_end - audio_position) /
-						default_asset->sample_rate :
-					result->video_do ? (double)(video_end - video_position) /
-						default_asset->frame_rate : 0;
-				if( remaining > 0 ) {
-					int jobs = total_packages - current_package;
-					package_len = remaining / jobs;
+				if(current_package < total_packages - 1)
+				{
+					package_len = (double)(audio_end - audio_position) /
+						(double)default_asset->sample_rate /
+						(double)(total_packages - current_package);
 				}
+
 			}
-		}
 
-		current_package++;
+                        current_package++;
 //printf("Dispatcher::get_package 50 %lld %lld %lld %lld\n",
 // result->audio_start, result->video_start, result->audio_end, result->video_end);
-	}
-	return result;
+                }
+                return result;
+
 }
 
 void PackagingEngineDefault::get_package_paths(ArrayList<char*> *path_list)
renderfarm.patch (5,352 bytes)
PhyllisSmith

PhyllisSmith

2024-06-12 00:20

manager   ~0005658

Last edited: 2024-06-12 00:20

View 2 revisions

Tested suggestions from Andrew but still flumoxed.
An interesting find is that in July, a patch was added to ensure that the Render Farm worked for a single frame AND IT STILL DOES NOW. Fix is in batchrender.C. Maybe this is a hint?

   Sun, 19 Jul 2020 18:09:46 -0600 (18:09 -0600)
   commit c9c0e07706fad701a70ee0d1ffb0fcb6304f138c
   tree 02dc23d65d09739fbd0942a5f6055e3adda95771 tree | snapshot (tar.gz tar.bz2 zip)
   parent d830901b11606a7838791bc45e39130329db99f0 commit | diff
   add timecode units/alignment/probe, add prefs auto_rotate,
   ffmpeg ssse3 patchB for flip/rotate, fix assetpopup deadlocks,
renderfarm 1frm render fix,
   resampleRT segv,info tweaks, plugin.opts vaapi tweaks

Andrew-R

Andrew-R

2024-06-09 15:51

reporter   ~0005650

@PhyllisSmith , thanks a lot for your work, I only noticed some i++ vs ++i changes, and probably change in starting number in output filenames when "file per label" set in renderfarm case ..
PhyllisSmith

PhyllisSmith

2024-06-08 00:58

manager   ~0005649

@Andrew-R
Render Farm failure starts here: 94fc059e6ed3f77f20531338cbb03bdb3b4d9eab
Render Farm previous works OK: 15411d7912d8aa1b9bea6ba8862517b058861771
I built it on an older version of Fedora and everything compiled.
Unfortunately the patches in the failing commit are too difficult for me to untangle.
PhyllisSmith

PhyllisSmith

2024-06-07 02:00

manager   ~0005648

@Andrew-R
Trying to narrow this down further and got closer.
    February 15, 2019 worked correctly.
    June 1, 2019 no longer working correctly.
I can not build these versions anymore (getting guicast/bcxxx.o errors) but maybe I can find old binaries to try on the desktop which I will look for tomorrow.
However, I am suspicious about "commit 94fc059e6ed3f77f20531338cbb03bdb3b4d9eab" which has modifications for "batchrender cleanup". The release notes state "Batch render cleanup" in the 03/01/2019 to 03/31/2019 section. I did look at those patches and they do relate to the render farm.
Andrew-R

Andrew-R

2024-05-30 23:26

reporter   ~0005643

yeah, I can confirm this bug using local renderfarm method.
It looks like rebdering pipelinealways starts from zero but correctly ends at selection end. So, we probably should seek to selection start before starting rendering for that case? Not sure how yet ...

Issue History

Date Modified Username Field Change
2024-05-30 19:31 PhyllisSmith New Issue
2024-05-30 23:26 Andrew-R Note Added: 0005643
2024-06-07 02:00 PhyllisSmith Note Added: 0005648
2024-06-07 02:00 PhyllisSmith Assigned To => PhyllisSmith
2024-06-07 02:00 PhyllisSmith Status new => confirmed
2024-06-08 00:58 PhyllisSmith Note Added: 0005649
2024-06-09 15:51 Andrew-R Note Added: 0005650
2024-06-12 00:20 PhyllisSmith Note Added: 0005658
2024-06-12 00:20 PhyllisSmith Note Edited: 0005658 View Revisions
2024-06-16 22:36 PhyllisSmith File Added: renderfarm.patch
2024-06-16 22:36 PhyllisSmith Note Added: 0005679
2024-06-16 22:38 PhyllisSmith Note Edited: 0005679 View Revisions
2024-06-17 04:38 Andrew-R Note Added: 0005680
2024-06-17 09:12 Andrea_Paz Note Added: 0005681
2024-06-17 20:45 PhyllisSmith Note Added: 0005682