 |
Closing because AT THIS TIME, there is no idea of how to improve this without potentially breaking something else. As requested, title changed to: "Stale image stays for one frame in composer after stepping backward". In addition it is important to note that what is being compared is the actual frame in the Compositor with the "Select start time" in the bottom of the Timeline's zoombar. As basically stated already, this is the "traditional behavior for Cinelerra" based on how the read_frame program routine operates. In both the forward and reverse cases the current position changes by 1 in the correct direction, but the image on the composer may be off by 1 depending on how you got to that position. It is not always just play 1 frame forward (shortcut 1) or play 1 frame in reverse (shortcut 4). For example if you just load the video, which sets the insertion pointer to 0, and then press 1 to go forward, it also "seems" to be 1 behind in the Composer or if you just load the video and immediately move the insertion pointer. It may appear quirky but if someone has a solution/patch that is better without any new quirks, that would be appreciated! Some variation on the behavior can be obtained by setting/unsetting a flag in Settings->Preferences, Appearance tab "Always show next frame". There was no intention of actually implying that there was an ffmpeg bug. It was just a funny attempt; same as in the Armageddon movie quote: "You realize we're sitting on 45,000 pounds of fuel, one nuclear warhead and a thing that has 270,000 moving parts built by the lowest bidder?" |
 |
@Sam: what about "Stale image stays for one frame in composer after stepping backward" ? |
|
|
@Andrew: "Should I make separate bugs for them? (if such problems still in CinGG codebase)." Yes, please as it makes it easier for me so that when I know GG is working in a specific area, I can throw that bug into the mix. As most people have probably figured out by now, GG does not read email or the forum so I have to read it and let him know about problems/bugs. Occasionally he will type in using my email / forum. Today he actually logged into the forum and typed himself !! "How I can extract required info - just increase loglevel for simple short video?" -- The easiest thing for me is to follow steps to reproduce the problem exactly (he makes me prove it is a bug first before he wants to hear about it!). The reason for that is because once we can reproduce the error, we can actually tell if it is fixed. Sometimes we have to provide a bug fix without knowing if it is a real fix or not and that is just a stab and may not work -- OR next best thing if error occurred and is not reproducable, send the dump file -- really, really should be as root user with gdb installed. If Cinelerra hangs without crashing, a Ctrl-C should produce a dump. Again, sometimes we have to analyze a dump where the user login is not root, but it is so much harder and only provides enough details to fix the problem about 10% of the time. -- Also, a session / demo file is very good because it is easy for him to follow the steps. |
 |
The headlines should always be short and concise. The proposed title is too long. |
|
|
what about "The expectation that the timeline "position" and the composer image ordinal should always match is not correct when the last play direction is reverse" ? Or this one is too long? |
|
|
Only moderators of the MantisBT can change the title. If you tell me the new title, I'll change it. |
|
|
Thanks for detailed explanation. My ascii-art was based on my own guess about what can be wrong in this case. I was totally off target ... But it seems this (traditional for Cinelerra?) behavior "but the image on the composer only agrees if you the play direction is forward." just confusing :/ Anonymous was thinking whole synchronization will be broken after such inconsistency. Can I rename bug title? |
 |
ok... I gave it more attention and it looks like it might be doing what it should as it is. The expectation that the timeline "position" and the composer image ordinal should always match is not correct when the last play direction is reverse. I think of the position as between the last frame and before the next frame. So, if you step/play up to frame 500, and then press step fwd you see this: Before step, position reads 500, composer reads 500. (step fwd) After step, position reads 501, composer reads 501. because the read_frame reads frame 501, the frame after the step position. Then, if you press step bwd you see this: Before step, position reads 500, composer reads 500. (step bwd) After step, position reads 499, composer reads 500. because the read_frame reads frame 500, the frame before the step position. In both cases the current position changes by 1 in the correct direction, but the image on the composer only agrees if you the play direction is forward. Since my test seems well behaved, and you describe a bug, I think I did not see what it is that you intend to demonstrate. The presentation time stamp (PTS) data is not actually visible anywhere except inside the codec file drivers, but it can change the "current_position" if the program current_position varies too far from the position determined by the PTS. This can occur when the data in the file is damaged or badly muxed. PTS data usually is only present at a rate lower than the packet delivery rate. For example, the bitrate may be 4M bits/sec (500K bytes/sec), and the packets typically are 2K bytes, so the packet rate is 250 pkts/sec, but timestamps may only be present only a few times per sec (1-5 typically) and the packets/frame count varies considerably with the content. So, using timestamp data for synchronization is inherently jittery if it is not exactly consistent with the playback time clock. The "timebase" is a clock rate that is used for timestamp granules. A very common timebase factor is the 27Mhz crystal used in the saa7114 video decoder. This clock is the basis for many derived clocks which try to treat the timeline as a rational fraction. Other codecs (like .mov) may just use a millisecond clock, which is really very grainy, which can jitter. I suspect you see a real issue, and I do not yet see what you see. I cannot correlate the ascii art data to any timeline events. Please expand on this, and if you can, produce a small demo of the problem described exactly so that I can produce the same session and set of events to see what is that you see. |
|
|
Hm, can I beg for a little more detailed explanation? FFmpeg used for nearly all multimedia processing in Linux apps (sometimes under many layers), so if this was really their bug it should be reported to them, at least. Can I try to acsii-art situation? ---*|--*-|---*|---*|---*|--*-|---*| ----- = time units | = idealized frame boundaries * = "presentation timestamps of real frames. So, when I ask Cin5 to move frame forward she just miscalculates 'jump distance'? Does this line sounds like something GG can potentially implement? https://git.cinelerra-cv.org/gitweb?p=einar/cinelerra.git;a=blob;f=README;h=a1f9d4f7f12af0ba2af810c5059c8d8c0cb8bec8;hb=HEAD 43 Changes of this fork: [...] 53 - composer and viewer always display the frame starting at the time 54 shown on clock. Frame displayed does not depend on 55 forward/backward direction. [...] 62 - implemented pts based timing on video and audio making possible 63 projects without constant framerate 64 - improved synchronization with Alsa output: no jumping around on playback 65 - removed playback direction dependancy from core rendering 66 - replaced samplerate based timing with clock based timing -------------- Should I make separate bugs for them? (if such problems still in CinGG codebase). How I can extract required info - just increase loglevel for simple short video? |
|
|
Turns out that most media has "presentation time stamps" in the packet data that determine the synchronization. The clock rates, inclusion rate, and other factors are really quite variable between codec, and codec interface implementation. There may be a way to get it to work a given series, but mostly cin5 will just ask for a certain frame, and show it to you. It usually can be coerced to create useful renderings. That is the goal. It would be nice if every case was flawless, but that may be just a wish. This is a direct quote from GG who was laughing while saying this: "All these codecs are being massively interfaced by 1 huge ffmpeg code space which was programmed by a whole bunch of unpaid developers. So press the button twice." |
- Anonymous
