In D10394#265234, @Justin Jones (jjones780) wrote:

I don't believe this can be assumed - but maybe there aren't enough cases to worry about? I'll see if I have any examples hanging around.

Similar as above, there is assumption that decoding any number of packets
in GOP chunk will produce same number of output packets. This must be
always true, otherwise we couldn't map proxy frames to original perfectly.

• Use only half of available threads to limit RAM usage with little to no performance impact. This could be probably handled better, I think that some systems may have HT disabled.
• Fix issue when after jumping to next GOP chunk there were less frames than lag of optput packets. This caused that output packets did 2 jumps at once resulting in gap which caused jobs to get stuck. Solution is to store jumps in large enough buffer. It's not nicest solution, but it works.

I don't believe this can be assumed - but maybe there aren't enough cases to worry about? I'll see if I have any examples hanging around.

Similar as above, there is assumption that decoding any number of packets
in GOP chunk will produce same number of output packets. This must be
always true, otherwise we couldn't map proxy frames to original perfectly.

I am concerned about the use of the deprecated FFMPEG functions here. At what point should we be switching to the newer FFMPEG api?

You can check 2.92, fix was done in both versions.

I tried to reduce it while keeping the problem: http://dl.free.fr/mhqZGjeum

In D10394#265041, @Olivier Jolly (zeograd) wrote:

With the current patch, it results in the progression indicator staying stuck (at 12% in my case). Cancelling the task doesn't finish (just showing "cancelling task...") and when trying to close blender, it doesn't respond properly, and I had to force kill it.
Without the current patch, the proxy progression goes up to 100% as expected.

The video is a montage of CC-0 and CC-BY footage that I can share if needed.

Unfortunately I can't check last build, because error at start: "api-ms-win-core-path-l1-1-0.dll not found". As far as I understand this library belongs Win 8 and higher. But I use Win 7.

I have one video which triggers a warning during proxy generation (with or without this patch)

In T85907#1117554, @Ivan (AIG) wrote:

https://youtu.be/WYwGJBhILxg
In the first part of video 2.93 and in the second part 2.83 LTS. Actually 2.91 behavior also strange

https://youtu.be/WYwGJBhILxg

Here are some mockups using the suggested naming schemes:

@Hans Goudey (HooglyBoogly) Isn't that very close to how it is now? Except you want Offset and Type are switched and Offset is the header of a sub panel?

it's nice to clarify the relation of these buttons, but I don't like the idea of moving the "Set Overlay Region" operator button to a tiny little square. We should avoid that wherever possible in my opinion.

• Fix GOP jumping implemented previously. Becasue output_packet_wrap can lag behind input, only increment it's index when it exceeds GOP size boundary.

• Make timecode index builder work correctly. Implementation is not nice at all.
• Fix missing frame with some files. Issue here was that 2 consequent packets were not decoded. solved by managing output packet index independently. After GOP jump, just set new index to same position as source packet. This must always work otherwise it wouldn't work even in previous implementation.

Include offset marker in patch.

• Use GOP chunks for packet reader lookahead

I like this in the view menu a lot better

• allocate transcode contexts on demand, otherwise this causes huge RAM usage with many strips
• Cleanup: consolidate structs
• Make sure cancelling transcoding is handled without crashing.
• Make TC builder not as bad. It is not working correctly, but it doesn't prevent adding strips now.

Expose in View menu.

• Fix thread condition interlock bug.

• Use thread conditions for waiting. Limit packet reading rate to packet writing rate. This is needed because if writing to slow drive, with big input files, RAM usage would be too high. Margin is currently arbitrary, but it must be big enough.

Note that indexer.c changes are ONLY related to upgrading to the newer ffmpeg calls and could be considered a separate revision.
Changes to anim_movie.c also include this upgrade as part of a larger fix.