Ticket #30 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

Correct H.264 importing in Matroska

Reported by: dconrad Assigned to: dconrad
Priority: normal Milestone: 1.1
Component: matroska Version:
Severity: normal Keywords:
Cc:

Description

At the moment, we pass crazy wrong durations for out-of-order frames to QTSampleTableAddSampleReferences(), and QuickTime manages to guess what we mean somewhat, but it breaks various things (like saving as .mov, seeking while paused, etc.) The correct way is to calculate the duration as the difference of timestamps in display order, and the offset the display time is from the decode time. This is complicated by the lack of restrictions on durations or number of b-frames, and the often incorrect duration stored by each frame, and Matroska not storing the decode timestamp, though maybe I'm just not seeing the easy solution.

Attachments

dts-calc.patch (8.3 kB) - added by dconrad on 03/20/07 22:54:06.
dts-calc3.diff (8.3 kB) - added by dconrad on 04/01/07 01:45:33.
InsertMediaIntoTrack? takes display timestamps/durations, but that still doesn't quite fix it; sometimes the display duration calculated in AddSamplesToTrack? is one greater than the decode duration, and that's when it fails. Subtracting 1 ms from the display duration makes it work, but I doubt this is correct.
dts-calc4.diff (6.2 kB) - added by dconrad on 04/02/07 12:12:52.
Patch (still incorrect) updated to apply on SVN again.

Change History

03/20/07 22:54:06 changed by dconrad

  • attachment dts-calc.patch added.

03/20/07 22:55:27 changed by dconrad

This doesn't quite work right; it randomly fails with -2014 (invalid duration) on adding the media to the track, but I can't see anything wrong with any of the durations calculated...

04/01/07 01:45:33 changed by dconrad

  • attachment dts-calc3.diff added.

InsertMediaIntoTrack? takes display timestamps/durations, but that still doesn't quite fix it; sometimes the display duration calculated in AddSamplesToTrack? is one greater than the decode duration, and that's when it fails. Subtracting 1 ms from the display duration makes it work, but I doubt this is correct.

04/02/07 12:12:52 changed by dconrad

  • attachment dts-calc4.diff added.

Patch (still incorrect) updated to apply on SVN again.

04/10/07 19:42:53 changed by dconrad

(In [405]) Reorder Matroska's pts to calculate dts so that the display offset can be set correctly. This isn't completely correct, since it needs to subtract 1 from the display duration when adding to the media sometimes, but it's a lot better than what we have now. Refs #30

04/18/07 18:18:15 changed by tick

  • milestone changed from 1.0 to 1.1.

Moving to 1.1. dconrad said this was cool, and we both agreed that if most people won't notice this we need to push this to 1.1 at the least.

04/27/07 13:11:47 changed by dconrad

  • owner set to dconrad.
  • status changed from new to assigned.

It seems that the -1 hack is causing issues such as #171 quite frequently (at least I've been noticing these frame skips at edit list boundaries a lot recently.) I'm going to try to fix this before 1.0b3.

04/28/07 22:38:14 changed by dconrad

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [476]) Calculate the duration of a frame between consecutive display timestamps rather than decode timestamps (this removes the need for the previous -1 hack.) Only import regions that don't have frames whose display offset would put them into the next. Finally correctly fixes #30 (hopefully)

05/01/07 06:31:21 changed by perian@nikwest.de

I have been following the matroska support for quite a while now, regulary building Perian from svn. I tested with 720p matroska/h264 files (Lost TV Show) and while the latest version r481 works on my Mac Book Pro it does not work on AppleTV. It either crashes Backrow (Finder) after a few seconds or does not show any video at all. I used the Deployment aswell as the AppleTV target. I am happy to provide some more information.

Thanks

Dominik

05/02/07 18:11:02 changed by perian@nikwest.de

An update on my previous comment. It seems like aTV is trying to use the QuickTimeH264.component for decoding and crashes (found out by looking at the crash dump). I removed the QuickTimeH264.component from the QuickTime folder and now there are no more crashes, but video playback is not playing back smoothly at all. Frequent drops in audio and video occure. Seems like aTV is not capable to play back 720p H264 with Perian (cpu is at 100%).