-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MFCopy produces incorrect duration when start and duration are specified #4
Comments
Using the existing sample and just changing the date stamp is the issue. There is some data in the sample that reflects the sample's current position, even though it is set via SetSampleTime. You have to copy the sample, but without calling CopyAllItems. Unfortunately, none of this is documented. |
So, do you happen to have a solution by any chance? If you submit a patch or pull request I will update the sample app. |
I am working on a solution. When CopyAllItems is not called, the duration is correct, but it introduces jittering in playback. I wish WMF was open source. |
It looks like the jitter is a different issue. If I take the original code and add a start position, I get jitter in playback on the resulting video. |
The attribute MFSampleExtension_DecodeTimestamp is the issue. This also causes the jitter because the decode time is not correct. Still working on the fix. |
This works for me. I copy the sample, except the DTS. The DTS for the destination sample is derived from the source sample time stamp and DTS. Add:
to _ProcessSamples. Release the destination sample when done. Derived from:
|
To be honest, I am not convinced it's exactly what needs to be done. That is, that the problem is with |
Here is a link to an example. The arguments:
produce a video that has the incorrect duration and where the video is jittery. |
With this command line parameters and the file MFCopy's remuxing is incorrect because it does not take prerolling into consideration. As image below shows video processing should start at 18.143s, then frames up to 20s need to be discarded (let me omit details for brevity). Instead the app converts 18.143s into 0.000s of output file. Audio track is also affected. So essentially the app will only work properly (more or less) if start time falls into IDR. The trimming function overall is pretty much broken in the sample, that is. |
These options create a video with five seconds of video, but the duration is 24 seconds.
-s 20000 -d 5000 inputVideo.mp4 testOut.mp4
The text was updated successfully, but these errors were encountered: