Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#6561 closed bug (fixed)

[MediaPlayer] crashes on playing wmv file

Reported by: diver Owned by: stippi
Priority: normal Milestone: R1
Component: Applications/MediaPlayer Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This is hrev38570 in VirtualBox. Before recent ffmpeg update this file used to play fine.

Thread 536 caused an exception: Segment violation
[...]
[Switching to team /boot/system/apps/MediaPlayer (480) thread playback manager (536)]
0x01efdaf0 in ff_msmpeg4_decode_init ()
   from /boot/system/add-ons/media/plugins/ffmpeg
   (gdb) bt
#0  0x01efdaf0 in ff_msmpeg4_decode_init ()
   from /boot/system/add-ons/media/plugins/ffmpeg
#1  0x0270c580 in ff_msmp4_dc_chroma_vlc ()
   from /boot/system/add-ons/media/plugins/ffmpeg
#2  0x00000009 in ?? ()
#3  0x00000078 in ?? ()
#4  0x02104c44 in ff_table0_dc_lum ()
   from /boot/system/add-ons/media/plugins/ffmpeg
#5  0x00000008 in ?? ()
#6  0x00000004 in ?? ()
#7  0x02104c40 in table_mb_non_intra ()
   from /boot/system/add-ons/media/plugins/ffmpeg
#8  0x00000008 in ?? ()
#9  0x00000004 in ?? ()
#10 0x00000000 in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000000 in ?? ()
#13 0x00000004 in ?? ()
#14 0x02598e5e in static_rl_table_store ()
   from /boot/system/add-ons/media/plugins/ffmpeg
#15 0x00003000 in ?? ()
#16 0x01efd5e4 in ff_msmpeg4_decode_init ()
   from /boot/system/add-ons/media/plugins/ffmpeg
#17 0x021af4a4 in ?? () from /boot/system/add-ons/media/plugins/ffmpeg
---Type <return> to continue, or q <return> to quit---
#18 0x1824fa90 in ?? ()
#19 0x021c3fa0 in wmavoice_decoder ()
    from /boot/system/add-ons/media/plugins/ffmpeg
#20 0xffffffff in ?? ()
#21 0x180e96a8 in ?? ()
#22 0x00003000 in ?? ()
#23 0xffffffff in ?? ()
#24 0x01f9fbf3 in wmv2_decode_init ()
    from /boot/system/add-ons/media/plugins/ffmpeg
#25 0x18040940 in ?? ()
#26 0x00000000 in ?? ()
#27 0x00003000 in ?? ()
#28 0x01f9fbc6 in wmv2_decode_init ()
    from /boot/system/add-ons/media/plugins/ffmpeg
#29 0x021af4a4 in ?? () from /boot/system/add-ons/media/plugins/ffmpeg
#30 0x18040940 in ?? ()
#31 0x021c3fa0 in wmavoice_decoder ()
    from /boot/system/add-ons/media/plugins/ffmpeg
#32 0x009e4b01 in BPrivate::hoardUnlock () from /boot/system/lib/libroot.so
Previous frame inner to this frame (corrupt stack?)
(gdb)

Attachments (1)

MediaPlayer_output.txt (4.0 KB) - added by diver 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by diver

Summary: [MediaPlayer] crashes on playing vmw file[MediaPlayer] crashes on playing wmv file

comment:2 Changed 9 years ago by diver

Confirmed, replacing ffmpeg binary from hrev38543 allows file to play.

comment:3 Changed 9 years ago by stippi

Can you provide a test file?

comment:4 Changed 9 years ago by diver

I guess, it's around 5mb where do you want me to upload it?

comment:5 Changed 9 years ago by diver

I tried to replace ffmpeg binary from recent nightly image and now MediaPlayer doesn't crash, but exits silently. See attachment. Interesting line is:

MediaTrackVideoSupplier::_SwitchFormat() - preferred color space: B_RGB24_BIG

I even tried to run this image (http://haiku-files.org/vmware/haiku-nightly-r38601-x86gcc2hybrid-vmware.zip) but MediaPlayer exits silently anyway.
Maybe this is related to the fact that I am running Haiku in VirtualBox?

Anyway, ffmpeg binary produced by my build env crashes MediaPlayer. I already tried to delete generated dir and even reconfigured compilers like this:

cd haiku/trunk/generated.x86gcc2
../configure --alternative-gcc-output-dir ../generated.x86gcc4 --build-cross-tools ../../buildtools/ --include-patented-code --use-gcc-pipe --distro-compatibility official --include-gpl-addons

cd haiku/trunk/generated.x86gcc4
../configure --alternative-gcc-output-dir ../generated.x86gcc2 --build-cross-tools-gcc4 x86 ../../buildtools/ --include-patented-code --use-gcc-pipe --distro-compatibility official --include-gpl-addons

Changed 9 years ago by diver

Attachment: MediaPlayer_output.txt added

comment:6 Changed 9 years ago by stippi

Hm, I don't really know what could be going wrong with your build, since there are many factors. In any case, I've tried with the file you've sent me. If you enable the ASF support in the FFmpeg plugin (see DemuxerTable.cpp, it's commented out), and remove the native ASF reader, you file seems to play reasonably. Although at the end, there seem to be some problems, and also when the file looped, audio was distorted at first. No crashes, though. There is definitely something wrong with the native ASF reader, I remember having lots of problems with garbled video when I still had some test files (those are on a harddisk which recently died).

comment:7 Changed 9 years ago by diver

After enabling ASF support in DemuxerTable.cpp MediaPlayer no longer crashes while playing support.vmw, but exits silently.
Last two lines from Terminal are:

Abort
Killed (by death)

comment:8 Changed 9 years ago by diver

This crash is not reproducible in the gcc4 build. Seems like gcc2 related issue.

Last edited 9 years ago by diver (previous) (diff)

comment:9 Changed 9 years ago by diver

BTW, mplayer plays this (support.wmv) file much better. No gray frames on winding.

comment:10 Changed 9 years ago by stippi

Well, what can I say... even the old VLC on Haiku plays some files much better than MediaPlayer. Integrating FFmpeg into a media player directly is very different from writing a Haiku Media Kit plugin which has to fullfill many more requirements: libavcodec needs to be separate in order to support other decoder/encoder plugins together with FFmpeg demuxers/muxers or the libavcodec codecs together with other Haiku readers/writers, each media stream needs it's own AVFormatContext, since FFmpeg as-is does not support seeking each stream individually, but that's required by our API. Also our MediaKit API shall support decoding audio/video in different threads, but FFmpeg can only demux in one thread. If I seek in ffplay, the code for that is very simple, because basically ffplay does not care where you seeked, as long as it is close enough to where you wanted. In the MediaKit, applications may require to seek to the keyframe before the requested frame, or to the one behind it, each stream independently. If I ignore that in the plug-in these applications don't work correctly. In FFmpeg each demuxer has a different quality. Yesterday I found out that even when you request from the FFmpeg API to seek to the keyframe before the requested position, some demuxers may seek to a later point in the file regardless. It's hard to get things right under these conditions. Something works well with one stream type and as soon as you try the next, the problems start all over again.

All in all, I am well aware that the FFmpeg plugin does not work perfectly for all types of files, but it *is* a little more complicated to get this right than what mplayer is doing. It also wouldn't help to design MediaPlayer around the defficiencies in FFmpeg, that doesn't help more demanding applications like Clockwerk.

comment:11 Changed 9 years ago by diver

Thanks for an explanation, it's much more clear now.

comment:12 Changed 9 years ago by stippi

Fixed in hrev38746. I have yet to test a build without ASF support in FFmpeg, but the stack crawl clearly points at the table initialization bug for GCC2 which I fixed in that revision.

comment:13 Changed 9 years ago by stippi

Resolution: fixed
Status: newclosed

comment:14 Changed 9 years ago by diver

Confirmed, thanks a lot!

Note: See TracTickets for help on using tickets.