0000436: Some TS clips are show to be 10 minutes long whatever their real length

Notes
(0001547) ddennedy (developer) 2008-12-06 19:32	Sample is shorter than repro case. Sorry, I thought you meant 10 seconds as originally reported. Sample also does not play in inigo for me, but it does in ffplay, which is something I will look into. Well, it plays a bit of audio, but no video. If you run 'ffmpeg -i original.ts' what duration is reported (if any)? 10 minutes at 25 fps is a "magic" number. It tells me ffmpeg was unable to report the duration and it fails over to this arbitrary hard-coded value. Maybe we should let one override/edit the duration reported in the Clip Poperties dialog to workaround this. Trying to determine the length each time the clip is opened by decoding all of it is not acceptable IMO.

(0001554) aaribaud (reporter) 2008-12-07 08:39	Sorry for the misnuderstanding about 10 seconds vs 10 minutes. Ffmpeg -i does not find the clip duration (says N/A). Note that Mplayer can play both video and audio. Maybe you could indeed allow manually setting the duration (or offer to do a full file scan on demand).

(0001730) ddennedy (developer) 2008-12-16 23:55	Still trying to decide what to do about this.

(0001954) ddennedy (developer) 2008-12-29 01:42	After the 0.7.1 release I have some fairly major changes in MLT to allow the length to be changed manually. These changes are in a local branch, but too extensive to commit requiring changes in kdenlive this late before the next release. I still might add the full scan on videos if the duration could not be determined.

(0004559) aaribaud (reporter) 2010-01-22 16:51	Still seeing the issue in 0.7.6. Making clip length modifiable in the clip properties would alleviate the issue even if not solving it cleanly.

(0004560) ddennedy (developer) 2010-01-22 19:21	Hmm, yeah this MLT code change never made it through because it breaks backwards compatibility and can affect a lot of apps. This problem is not reported much IMO to make it a real high priority, editing AVCHD is still quite unpleasant, and we are still recommending AVCHD users transcode to DNxHD for editing, which should work around this issue. So, currently, based on this and my priorities, this fix is on postpone/later status because I need to see if there is any way I can make it less breaking or if there is another highly compelling use case to really justify it.

(0004561) ddennedy (developer) 2010-01-22 19:24	Another possibly cleaner resolution is to submit a sample to the FFmpeg roundup bug tracker, and see if anyone on that project can fix it or give some good reason why it can not be determined.

Issue History
Date Modified	Username	Field	Change
2008-12-06 17:55	aaribaud	New Issue
2008-12-06 17:55	aaribaud	File Added: clipped2tenmins.ts
2008-12-06 17:55	aaribaud	Build/Install Method	=> Manual build from SVN
2008-12-06 19:32	ddennedy	Note Added: 0001547
2008-12-06 20:26	madsdyd	Status	new => feedback
2008-12-07 08:39	aaribaud	Note Added: 0001554
2008-12-16 23:55	ddennedy	Status	feedback => assigned
2008-12-16 23:55	ddennedy	Assigned To	=> ddennedy
2008-12-16 23:55	ddennedy	Note Added: 0001730
2008-12-29 01:39	ddennedy	Relationship added	related to 0000450
2008-12-29 01:42	ddennedy	Note Added: 0001954
2009-01-28 19:58	ddennedy	Relationship added	related to 0000588
2009-01-28 22:08	ddennedy	Relationship added	has duplicate 0000623
2010-01-22 16:51	aaribaud	Note Added: 0004559
2010-01-22 19:21	ddennedy	Note Added: 0004560
2010-01-22 19:24	ddennedy	Note Added: 0004561