View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007286 | MMW v4 | Player | public | 2011-02-01 19:48 | 2011-05-13 00:00 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0007286: Playing .mov files crashes MM | ||||
| Description | With build 1246, and codec pack 1.09, if the user tries to play a .mov file from a canon camera, MM first generates a warning that subtitles cannot display (even though no subtitles are present) and then crashes. elog submitted. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1360 | ||||
|
|
Note: it appears that the elog did not submit successfully (MM crashed completely before the elog was sent). I've previously submitted a canon camera .mov file, though, so it should be reproducible. Let me know if not. |
|
|
Here is the error that appears: Debug Error! Program: C:\Programe Files (x86)\MediaMonkey4\MediaMonkey.exe Module: C:\Programe Files (x86)\MediaMonkey4\Plugins\f_video.dll File: Run-Time Check Failure #3 - The variable 'txt' is being used without being initialized. (Press Retry to debug the application) Note: -DebugView doesn't show any useful debug information. -The error warning re. subtitles only occurs sometimes. -The bug doesn't occur with AVI files from the canon camera--only with .MOV files from the camera -Windows Media Player also has a problem playing the file (it generates an error that 'there is a problem playing the file' after a couple of seconds of playback--but it doesn't crash) -I've posted a sample file at: https://www.yousendit.com/download/MzZFb245Q1I5RmJ2Wmc9PQ |
|
|
Fixed in build 1347. I've reproduced the problem only in Win7 using the given MOV file. |
|
|
The sample video worked on 1348 here, but this sample fails on import: http://feedproxy.google.com/~r/dailyplanettv/~5/VN3rt5-cWVo/Exo-trainer_coming_soon.mov It fails both when imported as part of the Podcast or when the file is saved on PC and imported as video file. |
|
|
I've replicated the issue with http://feedproxy.google.com/~r/dailyplanettv/~5/VN3rt5-cWVo/Exo-trainer_coming_soon.mov by downloading it to HDD. File plays (Audio Only, video is locked on first frame), but Seek and Thumb Creation (Import) Crashes MM. GPOT 2.70 shows correct QT Container and plays the file. Eureka Log and file are uploaded to FTP. |
|
|
This file has very strange structure - it has avc1 video stream at the beginning, and after cca 3s it switches to mp4v. It is the reason why classic playback does not work - it adds avc1 decoder during playback graph creation, and this decoder crashes or stops decoding after 3s (then it receives wrong data). The only way, I think, how to play this file, is to use some wrapper to QuickTime API as source filter, I have already tested one, will see if we will use it later. |
|
|
To resolve, codecs would be used in the following order: For all formats but mov: 1) Via MM codecs & system codec 2) If not playable via Quicktime (if relevant/available) 3) If not playable, dl codec For mov format: 1) Via Quicktime (if available) 2) If not available try via MM codecs & system codecs 3) If not playable, dl quicktime (using existing code & strings already exist re. AAC) Notes: MM should 'know' as much as possible what codecs/options described above are available so that playback is instantaneous. The current AAC-related strings should not be used, since they are specific to AAC. MM should instead use the codec download framework to link to am MM-site location that would provide more details (see 0006493, and please update 0006493 with relevant information). |
|
|
Fixed in build 1356. QuickTime 7 or higher will be needed for reliable playback/decoding of all MOV files, for MOVs it will be prefered. We will use QuickTime also for 3GP playback and for MP4 playback in case of missing MP4 splitter. Because I found out that the QuickTime H264 decoder is quite HW consuming (especially for Full HD), we will prefer MP4 splitter and ffdshow codecs for MP4. We still can play a lot of MOV files without QuickTime, but it will be less reliable. |
|
|
Re-opening for discussion: This sounds like a partial solution for the case of .mov files. It seems that the implementation: 1) Attempts to play with QT (if installed) 2) Plays with system codecs / MM codecs if QT not available BUT, in case 2), user will run MM for the first time, scan will proceed, thumbnails generate --> crash --> user uninstalls MM! So we have a workaround now, but if MM still crashes, it doesn't solve the original bug. Possible solutions: 1) Make MM fail gracefully when attempting playback/thumbnail generation for .mov files 2) If QT isn't available, prompt the user to install QT for .mov files (and never use MM codecs for thumbnail generation) On the other hand, if .mov files that trigger a crash are so rare, perhaps we should just leave as is... |
|
|
Reminder sent to: jiri Jiri, please review with Michal re. best way to proceed. |
|
|
As discussed over IM, we should be able to fail gracefully in case of problems in third-party code by embedding the whole decoding/encoding/playback framework to another Windows process. It's quite a change, but shouldn't be that hard to implement. Note that if properly implemented, it should resolved problems in 0007533, since threading issues will no longer be a problem in multiple processes. |
|
|
Fixed in build 1360. From now on, video will be played and converted in separate process(es). |
|
|
Verified 1373 |
