5 ms·

The most questionable thing is why did they keep the assert in production code. Looks like unfinished job to me.

by etix 12y ago

bennyg 12y ago
That's how I feel when I read through Android documentation with most things: this just seems unfinished.
jpk 12y ago
When given the option to either abort the process or put hardware into an unrecoverable state and requiring a reboot, you leave the assert in for production.
- jbk 12y ago
  Oh come on, this is just ridiculous. This is a process that is parsing a MKV or MP4 file. Nothing that needs hardware decoding. Failing to parse a file should not abort a process. Multimedia is about parsing broken files!
  - jpk 12y ago
    There's demuxing and there's decoding. Demuxing can easily be done in software where it can fail gracefully. Decoding is computationally expensive and can't be done in software. On many devices, software decoders are too slow to decode a frame of video before it's too late to display, so you have to drop frames. Some software codecs refuse to even attempt to decode h264 of a profile/level above baseline/2.1. So instead, decoding is done in hardware using finicky SoCs that don't always make it possible to fully meet the OpenMAX IL spec. In fact most device makers hack up OMXCodec and other classes in libstagefright to get the higher level Android media APIs to work. All this code is littered with CHECK()s probably because Google can't do any better due to hardware being too fragmented (what you would do to recover from a hosed decoder might work on one phone, but not another). And device makers don't because either 1) once they hack up their ROM to get the YouTube app working, they just ship the device, or 2) implementing a way to recover would require a hardware change and ain't nobody got time fo dat.
    - cpeterso 12y ago
      Android's Stagefright does include CHECK()s that are unrelated to hardware decoding, such as MP4 demux parser code that could easily just return an error code but instead aborts your process.
      - jbk 12y ago
        Exactly. This is exactly the problem here, Android System is going to scan your media collection in your back, and by doing so, will crash your media player and may even reboot your phone.

The most questionable thing is why did they keep the assert in production code. Looks like unfinished job to me.

by etix 12y ago

The most questionable thing is why did they keep the assert in production code. Looks like unfinished job to me.

bennyg 12y ago

That's how I feel when I read through Android documentation with most things: this just seems unfinished.

jpk 12y ago

When given the option to either abort the process or put hardware into an unrecoverable state and requiring a reboot, you leave the assert in for production.

jbk 12y ago
Oh come on, this is just ridiculous. This is a process that is parsing a MKV or MP4 file. Nothing that needs hardware decoding. Failing to parse a file should not abort a process. Multimedia is about parsing broken files!
- jpk 12y ago
  There's demuxing and there's decoding. Demuxing can easily be done in software where it can fail gracefully. Decoding is computationally expensive and can't be done in software. On many devices, software decoders are too slow to decode a frame of video before it's too late to display, so you have to drop frames. Some software codecs refuse to even attempt to decode h264 of a profile/level above baseline/2.1. So instead, decoding is done in hardware using finicky SoCs that don't always make it possible to fully meet the OpenMAX IL spec. In fact most device makers hack up OMXCodec and other classes in libstagefright to get the higher level Android media APIs to work. All this code is littered with CHECK()s probably because Google can't do any better due to hardware being too fragmented (what you would do to recover from a hosed decoder might work on one phone, but not another). And device makers don't because either 1) once they hack up their ROM to get the YouTube app working, they just ship the device, or 2) implementing a way to recover would require a hardware change and ain't nobody got time fo dat.
  - cpeterso 12y ago
    Android's Stagefright does include CHECK()s that are unrelated to hardware decoding, such as MP4 demux parser code that could easily just return an error code but instead aborts your process.
    - jbk 12y ago
      Exactly. This is exactly the problem here, Android System is going to scan your media collection in your back, and by doing so, will crash your media player and may even reboot your phone.