 |
Hm, not sure if I understand? Trying to think out loud .. What if we have somefile 35 frames big. codec keyframes are at 1, 25, 31 so, we cut it at frame 23, and move second half two frames back on another track. so, for frame 21 we just request frame 21 after 20 - > all fine. next we request frame 22 and 23 -2 = 21 ? and next we req 23 and 23 - 1 = 22 ? if all those frames in cache (but for this cache (section? slab?) must be per-file, and not per-track?) caching system must be intelligent enough for just giving them up to mixing, without re-requesting decoding? I mean, isn't this basic of those L, and J-cut techniques described in manual? I come with extreme case of moving second half all way back to overlap first half nearly completely, THIS can be slow at initial playback at least because you request two frames from separate parts of file, and it may just be worst-case scenario (for IBP codecs). But just few frames {actually, seconds} overlap seems to be important for transitions? |
 |
So GG in looking at this issue (while debugging caching for transitions and reverse play) determined that caching while playing forward actually caused problems and made it slower. So that does not help for this case. No other ideas at this time so proxy may be the only help but I do not understand why and will let gg know so maybe there will be an explanation that helps for improvement. |
|
|
I think use of proxy file (at 1/3 of 1080p media) "fixes" this, but not everyone works with proxies ? |
|
|
@Andrew-R About your "Wild idea", GG says that it is essentially mostly already done this way, so it is not really wild idea. He is going to try out your scenario today hopefully. |
|
|
Wild speculations (I was unable to profile cin, probably because I have stripped version of binary installed, but this never stopped me from speculating!): May be Cinr euqests frames from ffmpeg (libavcodec) in 'wrong' order? Like, for highly-compressed (I- and P- frames) stream we ask for frame 100, and then for frame 98, and then for frame 99, and then for 90? And libavcodec, while playing nicely forward (90-91-92 ... 100) choke on reverse direction? Wild idea: On media load, along with usual indexes build map of all keyframes (I-frames) for all I{B}P type of codecs. Then when upper layer of Cin will ask for frame we don't ask libavcodec directly to fetch it, but first calculate nearest 'left' and 'right' codec keyframes (I frames) around requested frame, tell libavcodec to start decoding this range, into dynamically allocated buffer, and after we got our frame we can move forward, or backward, anywhere around GOP (hold in memory). Yes, this will increase memory usage. But hopefully will eliminate (lessen) reverse playback slowness, too. With some possible future benefits of 'direct cuts', based on this codec-keyframe information. |
- Anonymous
