Opened 7 years ago

Closed 5 years ago

#8856 closed bug (invalid)

Libavcodec has been miscompiled

Reported by: mmadia Owned by: korli
Priority: normal Milestone: R1
Component: Applications/MediaPlayer Version: R1/Development
Keywords: Cc: HubertNG@…
Blocked By: Blocking: #11175
Has a Patch: no Platform: All

Description (last modified by pulkomandy)

hrev44483 gcc2h

~/Desktop> MediaPlayer Nexus\ 7\:\ Camping 
open playlist item: Nexus 7: Camping
Compiler did not align stack variables. Libavcodec has been miscompiled
and may be very slow or crash. This is not a bug in libavcodec,
but in the compiler. You may try recompiling using gcc >= 4.2.
Do not report crashes to FFmpeg developers.
Kill Thread
~/Desktop> 

Change History (16)

comment:1 Changed 7 years ago by korli

No way to fix on GCC2. That's why SSE is disabled on GCC2.

comment:2 Changed 7 years ago by mmadia

So far, I have not found any video that will play on hrev44483-gcc2h.

comment:3 Changed 7 years ago by leavengood

Hmmm, maybe we have to downgrade the version of ffmpeg again :/

I look forward to the day when we can relegate gcc2 to the BeOS and Haiku dustbin of history.

comment:4 Changed 7 years ago by korli

I tested against gcc2 and nothing is played. I don't think I'll have time to investigate this in the next couple of weeks. Sorry about that. Please revert the change if needed.

comment:5 Changed 7 years ago by mmadia

Reverted in hrev44531. Should this be kept open, as the real issue with Libavcodec on GCC 2 hasn't been fixed?

comment:6 Changed 7 years ago by axeld

That would make sense, yes.

comment:7 Changed 7 years ago by pulkomandy

It seems possible to keep the newer version of ffmpeg for gcc4 and the old one for gcc2. This would need some tweaks to the affected code, but looking at the commit there isn't too much.

This would work the same as OpenGL (we now use different versions of Mesa for gcc2 and 4). At least the gcc2 problems won't affect gcc4 apps and users.

comment:8 Changed 7 years ago by diver

Milestone: R1/alpha4R1

comment:9 Changed 7 years ago by Hubert

"This would work the same as OpenGL (we now use different versions of Mesa for gcc2 and 4). At least the gcc2 problems won't affect gcc4 apps and users."

+1 Thx.

comment:10 Changed 7 years ago by Hubert

Cc: HubertNG@… added

comment:11 Changed 5 years ago by korli

Blocking: 11175 added

comment:12 Changed 5 years ago by waddlesplash

It appears this one has cropped up again with FFmpeg 0.10.14. I think at this point we should make MediaPlayer, MediaConverter, and anything else that uses the Media Kit GCC4 if it's possible.

comment:13 Changed 5 years ago by pulkomandy

Well, as mentionned earlier in the ticket, this doesn't seem to be an actual problem for MediaPlayer, which plays everything we throw at it just find and without any crashes.

MediaConverter fails to work for other reasons, as it also doesn't work on gcc4 IIRC.

So what would that fix?

Moreover, we still need to provide media decoding to gcc2 compiled apps, and ffmpeg seems to do the job just fine. What about we patch ffmpeg to remove that annoying message? At this point we can be fairly sure that it works anyway (most likely because we compile it with SSE2 disabled) and that it's safe to continue using it that way.

comment:14 Changed 5 years ago by waddlesplash

It would fix the problem that media playback is (possibly) slow/inaccurate due to lack of all SSE*/MMX* in FFmpeg on GCC2. FFmpeg is pretty much untested without SSE/MMX (IIRC) and so we're kinda in dangerous waters on this.

On the other hand, GCC4 FFmpeg has all those compiled in, so FFmpeg can choose which to use based on the CPU.

comment:15 Changed 5 years ago by pulkomandy

Description: modified (diff)

You are trying to fix a non-existing problem here. We have been using ffmpeg this way for years without any problems. Moreover, the computers on which we want FFMPEG to be super fast (because the computer is slow) are precisely the ones which don't support SSE2. Morever, that codepath is also used on many non-x86 archs so it's actually quite well tested on FFMPEG side, so there isn't much to worry about there.

If you can find files that are actually problematic to replay in MediaPlayer, we can reconsider this.

comment:16 Changed 5 years ago by waddlesplash

Resolution: invalid
Status: newclosed

Very well then, resolving as invalid. If anyone has media files that do not play properly, please file separate tickets.

Note: See TracTickets for help on using tickets.