MediaPlayer crashes on HD Video

[vidrep]

hrev49863 x86_gcc2 AVCHD (.mts) video crashes MediaPlayer (MediaPlayer-1100-debug-21-11-2015-00-19-33.report) (MediaPlayer-1134-debug-21-11-2015-00-19-45.report 4K UHD (.mp4) video crashes MediaPlayer MediaPlayer-1167-debug-21-11-2015-00-19-56.report) SD 640x480 (.avi) plays perfectly

[ttcoder]

Looks like it might be the debugger() call added around line 900 of this ​changeset, if so, someone Cc pulkomandy :-)

He'll maybe need a reproducible case from you vidrep

EDIT: wait, I'm probably wrong, I think pulkomandy said the ffmpeg2.8 code only affects WebPositive, not MediaPlayer ?

[pulkomandy]

The code in the media add-in affects both sides. MediaPlayer still uses ffmpeg 0.10 but it goes through this same code. It seems ffmpeg 0.10 is failing to do the resample. Note that this is for the audio part, and probably unrelated to the video codec and container.

So yes, it would be nice to have some sample files, possibly only with the audio but I'm not sure if there is a tool to extract only the audio track from a file without conversion or reencoding.

[vidrep]

MediaPlayer wasn't handling these file formats so well before it starting crashing. i'll see if I can provide a link to test cases that reproduce the crash, or find a tool on another platform that than extract the audio data from my files. It would be nice if we could get ffmpeg 2.8 going on gcc4 builds, while at the same time fixing gcc2 within its inherent limitations.

[vidrep]

Using hrev49882_x86_gcc2 and x86_64 builds for this test.

test.AVI (attached) test.MTS (attached)

32 bit Haiku plays test.AVI on MediaPlayer without issue 64 bit Haiku crashes with test.AVI on MediaPlayer

test.AVI_x86_gcc2_log (attached) test.AVI_x86_64_log (attached)

32 bit Haiku crashes with test.MTS on MediaPlayer 64 bit Haiku plays test.MTS on MediaPlayer without issue

test.MTS_x86_gcc2_log (attached) test.MTS_x86_64_log (attached) MediaPlayer-774-debug-26-11-2015-02-26-50.report (attached)

This ticket is related to #12502

[vidrep]

The original test.MTS file was too large to upload. I have attached a smaller file (test2.MTS) that will reproduce the crash in MediaPlayer on x86_gcc2 builds.

[ttcoder]

Well wow.. I've updated to hrev48884 (my test machine, not prod, fortunately :-) and I (mostly) can't play audio without getting this failed assert any more, be it in MediaPlayer or SoundPlay or anything .. Playing video (movies) works great here.. as does two .flac audio files, but other .flac files and all mp3 files trigger the assert. I've emailed Dane to NOT update his test (let alone production) machines any more for now.

Someone Cc me to this ticket (for dashboard purposes, I know for email purposes I'm already cc'ed).

It seems I'm experiencing the exact same bug as this ticket, but if needed I could file a separate ticket with appropriate properties (blocker -- since you can't ship an OS that won't play audio ;->, component = media/codecs kit, title = "BMediaFile trips assert on audio and/or video files")

What's weird is that I updated from hrev49877, there were no relevant git commits inbetween, and I remember playing audio successfully in that older rev.. How is that possible. Maybe I remember wrong. For the record my recent update history was {49884, 49877, 49853, 49847}.

Edit: BTW 49877 was installed from a nightly, whereas 49884 was pkgman up'ed, if that matters (should not, I guess)

Edit2: How reproducible is that for you guys (pulkomandy esp.) ? Also, I don't want to come across on a negative tone by reporting all this ! I'm seeing performance improvements in many domains, youtube videos work better than they ever had (minus the 2x problem tracked elsewhere) seems the ffmpeg upgrade brought lots of improvements and just needs to be ironed out, and last week's nightly looks like it works well for us, so you guys keep up the good hacking :-)

[ttcoder]

"resampling failed" after double clicking an mp3

[vidrep]

Updated from hrev49882 to hrev49888 on 64 bit Haiku, and now none of the video files I tested with yesterday are working - all cause a MediaPlayer crash. Opening Webpositive also causing a crash (reloading YouTube as last page).

[vidrep]

Attached are debug reports for the two HD video files which were playing perfectly just yesterday with hrev49882 x86_64.

[korli]

Well, between hrev49882 and hrev49888 there is only one change affecting x86_64, it's a package addition, nothing leading to such a problem. Can you check that when you start up hrev49882 in the boot menu, video which were working are still working? Could it be eventually related to the chosen builtbot slave?

[ttcoder]

Aren't those last 2 crashes a different issue ? Looks like a fairly 'interesting' one though, from the back trace:

0x7f73b9ce9fb8  0x1df48420d0e   CzWINDOWEDFIR::CzWINDOWEDFIR(void) + 0xfe (/sources/libmodplug-0.8.8.5/src/fastmix.cpp:248
0x7f73b9ce9fd8  0x1df4840f968   _GLOBAL__sub_I_fastmix.cpp(void) + 0x38

I wonder if it's normal to use a (Protracker) MOD files' resampling routine instead of the ffmpeg one.. Seems that stems from a global variable..

Very very wild speculation here (and I learned in the past that I should apologize in advance before doing such :-), but is it possible that there are several global variables with the same name, and at runtime, the "sub_fastmix" symbol might be resolved to the wrong library/add-on, depending on which add-on gets resolved/loaded first? Apologies if that is a dumb question.

[vidrep]

Before seeing korli's response I did a fresh install of hrev49882 x86_64, then started doing pkgman updates one revision at a time to see when the problem occurs. It didn't take long - hrev49833 is the culprit.

[pulkomandy]

There is only one add-on. The problem is more likely that ffmpeg now support protracker MOD files (I enabled that), and apparently misdetects a file as some MOD format and uses the wrong decoder.

@vidrep: are you sure the crash isn't random? Have you tried several time on the same revision? If it doesn't happen 100% of the time it is a bit more difficult to debug.

Also, an useful thing to do is running MediaPlayer or WebPositive from terminal. The ffmpeg decoding is quite verbose, so you will see a lot of things in Terminal, which may be attached to tickets for additional info.

[vidrep]

I tried to download the hrev49887 x86_64 anyboot image with hrev49883 to see if a fresh install of that had the same problem, but Web+ now crashes on any download attempt. If I open Web+ from the terminal, there is a error message about SSL certificates before crashing. I'll open a seperate ticket for that once I go back to hrev49882.

[vidrep]

Pulkomandy,

The reports I attached yesterday were all run from the terminal (test.MTS_86_64.log, etc). I have been at this most of the morning, and it is 100% reproduceable. hrev49882 works, 49883 and later don't work.

[pulkomandy]

The two changes in hrev49883 look completely unrelated to media decoding. There is an update of openssl and Qt4, with only packaging changes (it should be the same code running), and there is a minor build fix in app_server. I don't see how these could trigger a problem in MediaPlayer.

If this exact revision breaks things for you, it is probably a buildbot acting strange again. I would recommend building Haiku yourself, to see if that also reproduces the problem? The crash is during load_library, which apparently triggers some static init in libmodplug. It could be that depending on the order the libs are loaded (which may depend on in which order they were added to the haiku image), we get a different result here. Maybe we should disable the libmodplug support again, or see if there is an updated version which helps with the problem.

[korli]

hrev49883 and hrev49887 are both built by arfonzo-bot1-debian. Does hrev49884 also crash?

[vidrep]

korli,

You're on to something. I did a fresh install of 49882, verified that the videos work, then did a pkgman update to 49884. They do work on 49884. Web+ does not crash on downloads either. Anything else to check?

[vidrep]

Update: I downloaded hrev49887 x86_64 anyboot image, burned it to CD and did an install. It works the same as hrev49882 (64 bit). I have not checked 32 bit yet. So, what do 49883, 49885 and 49888 have in common, other than they crash all the time on almost every app?

[ttcoder]

Replying to korli:

hrev49883 and hrev49887 are both built by arfonzo-bot1-debian. Does hrev49884 also crash?

FWIW, that bot was put off line a few weeks ago: https://dev.haiku-os.org/ticket/11174#comment:31

Maybe someone fixed it and put it back online ?

[korli]

Replying to ttcoder:

FWIW, that bot was put off line a few weeks ago: https://dev.haiku-os.org/ticket/11174#comment:31

Maybe someone fixed it and put it back online ?

Good to know. Seems the problem isn't fixed then. To be noticed this bot builds with -j16, where as geist's bots build with -j2. A more conservative value should be used IMO.

[vidrep]

Korli, Updating from a fresh install of hrev49887 (working) to hrev49888 (not working). Is this a problem with the build bot as you suspect? So, in a nutshell, here are the results: 49882 - working 49883 - not working 49884 - working 49885 - not working 49886 - working 49887 - working 49888 - not working All tests done using the same video files, same PC. I'll go through the x86_gcc2 builds next to see if the same revisions are affected by this bug.

[vidrep]

Using fresh installs of x86_gcc2 builds I got the following results: 49824 - working 49856 - working 49863 - not working It appears either of the changes in 49858 or 49862 is causing MediaPlayer to crash on 32 bit builds when attempting to play HD videos. Previously they just stuttered but didn't cause a MP crash. It looks like we have several different issues at play here. Maybe it would be best to close these last few tickets of mine and start from scratch, keeping 32 bit and 64 bit ffmpeg related issues separate. Let me know what you decide to do. Sorry for the confusion.

[Barrett]

Just wanted to mention that i tested both files today and they don't crash under gcc4h. I'm of course building Haiku by myself.

[vidrep]

This ticket can be closed as it has been superseded by ticket #12509.