http://bugs.cinelerra.org/show_bug.cgi?id=269
------- Additional Comments From [EMAIL PROTECTED] 2006-06-08 20:44 ------- Ok, here's what I've found out: Most of the sample videos exhibiting the problem with the video track being truncated are using Sony MPEG HQ(X) or VX format (see http://www.camcorderinfo.com/bbs/showthread.php?t=62507 for reference). These videos use blocks of 0x20000 bytes containing 6 GOPs, of the pattern: I IP I IP I IP The P frame in every other GOP is a dummy frame. The file frame rate is 25.00fps but in actuality the dummy frame just copies the previous iframe, so only 2 of every 3 frames have new content. The 25 fps MPEG is actually filmed at 24 fps, divided by 3 frames = 8, subtract that for the dummy and you actually have a 16fps file where every third frame could be discarded. Not sure of the best way to handle that. But all that aside, the reason the video comes out way shorter than it should is due to the method used by mpeg3tocutil.c to scan for start codes - as it is, it ends up skipping bytes at times. In most cases, the frame sizes are long enough that those bytes don't matter. But in the case of these files, where the dummy P frame is only an average of 63 bytes, you end up losing some frames in each block as the file is demuxed. The patch I'm attaching will fix the start code seek problem, but it doesn't fix the problem with the audio length being miscalculated. Also, the end of the audio track and the end of the video track are still slightly off... not sure if that is the fault of the parser or if it is just the way these MPEG files are generated by the camera. Anyone else want to take a look at it? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
