Recherche avancée

Médias (91)

Autres articles (106)

  • Keeping control of your media in your hands

    13 avril 2011, par

    The vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
    While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
    MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
    MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

  • Personnaliser les catégories

    21 juin 2013, par

    Formulaire de création d’une catégorie
    Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
    Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
    On peut modifier ce formulaire dans la partie :
    Administration > Configuration des masques de formulaire.
    Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
    Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...)

Sur d’autres sites (10172)

  • Chrome times out on streaming FFMPEG output from ASP.NET Web Api

    3 août 2014, par Hayden McAfee

    I’ve got a unique problem here !

    UPDATE 2 So it turns out the development below is FALSE, the inconsistency of the bug made it seem like not closing the stream made it work... but in fact the same issue persists !

    UPDATE Interesting development ; if I comment out ffmpegBufferedIn.Close(); below, the entire stream always goes through fine... the request just never ends. What could be going on here ?

    I’m writing a web service that stores audio files in Azure Blob Storage, and converts them to MP3 live when requested through my ASP.NET Web API endpoint. I accomplish this by using ’DownloadToStream’ via the Azure Storage API, feeding that stream through the STDIN of an FFMPEG process, and sending the STDOUT stream as the request response.

    The block of code that does this looks like this :

    public HttpResponseMessage Get(Guid songid)
    
{
    
    // This could take awhile.
    
    HttpContext.Current.Server.ScriptTimeout = 600;
    

    
    Process ffmpeg = new Process();
    
    ProcessStartInfo startinfo = new ProcessStartInfo(HostingEnvironment.MapPath("~/App_Data/executables/ffmpeg.exe"), "-i - -vn -ar 44100 -ac 2 -ab 192k -f mp3 - ");
    
    startinfo.RedirectStandardError = true;
    
    startinfo.RedirectStandardOutput = true;
    
    startinfo.RedirectStandardInput = true;
    
    startinfo.UseShellExecute = false;
    
    startinfo.CreateNoWindow = true;
    
    ffmpeg.StartInfo = startinfo;
    
    ffmpeg.ErrorDataReceived += ffmpeg_ErrorDataReceived;
    

    
    // Our response is a stream
    
    var response = Request.CreateResponse();
    
    response.StatusCode = HttpStatusCode.OK;
    

    
    // Retrieve storage account from connection string.
    
    CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
    
        CloudConfigurationManager.GetSetting("StorageConnectionString"));
    

    
    // Create the blob client.
    
    CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
    

    
    // Retrieve reference to a previously created container.
    
    CloudBlobContainer container = blobClient.GetContainerReference("songs");
    

    
    // Retrieve reference to a blob
    
    CloudBlockBlob blockBlob = container.GetBlockBlobReference(songid.ToString());
    

    
    ffmpeg.Start();
    
    ffmpeg.BeginErrorReadLine();
    

    
    // Buffer the streams
    
    var ffmpegBufferedIn = new BufferedStream(ffmpeg.StandardInput.BaseStream);
    
    var ffmpegBufferedOut = new BufferedStream(ffmpeg.StandardOutput.BaseStream);
    

    
    blockBlob.DownloadToStreamAsync(ffmpegBufferedIn).ContinueWith((t) => {
    
        ffmpegBufferedIn.Flush();
    
        ffmpegBufferedIn.Close();
    
    });
    

    
    response.Content = new StreamContent(ffmpegBufferedOut);
    
    response.Content.Headers.ContentType = new MediaTypeHeaderValue("audio/mpeg");
    

    
    System.Diagnostics.Debug.WriteLine("Returned response.");
    
    return response;
    
}

    This works quite well in all browsers - all except for Chrome, which has an interesting way of buffering audio streams. Chrome will buffer the first 2 megabytes of a stream, then keep the connection open and wait until the user gets closer to playing the next segment of a file before consuming the rest of the stream. This should be fine - and for some songs it is. For others, I get this :

    Chrome error

    At first I thought this was due to some kind of timeout - But it happens at a different time and size for each file. It is consistent within about 15 seconds on the same songs, however. The output on the server side is normal - no exceptions thrown, and FFMpeg finishes encoding the song successfully.

    Here’s the server-side output of the above request :

    ffmpeg version N-64919-ga613257 Copyright (c) 2000-2014 the FFmpeg developers
    
  built on Jul 23 2014 00:27:32 with gcc 4.8.3 (GCC)
    
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
    
  libavutil      52. 92.101 / 52. 92.101
    
  libavcodec     55. 69.100 / 55. 69.100
    
  libavformat    55. 48.101 / 55. 48.101
    
  libavdevice    55. 13.102 / 55. 13.102
    
  libavfilter     4. 11.102 /  4. 11.102
    
  libswscale      2.  6.100 /  2.  6.100
    
  libswresample   0. 19.100 /  0. 19.100
    
  libpostproc    52.  3.100 / 52.  3.100
    
Input #0, mp3, from 'pipe:':
    
  Metadata:
    
    TSRC            : AUUM71001516
    
    title           : Sunlight
    
    track           : 2
    
    artist          : Bag Raiders
    
    copyright       : 2010 Modular Recordings
    
    genre           : Electronic
    
    album           : Bag Raiders
    
    album_artist    : Bag Raiders
    
    disc            : 1/1
    
    publisher       : Modular Recordings
    
    composer        : Chris Stracey/Jack Glass/Dan Black
    
    date            : 2010
    
  Duration: N/A, start: 0.000000, bitrate: 320 kb/s
    
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
    
    Stream #0:1: Video: mjpeg, yuvj420p(pc, bt470bg), 600x600 [SAR 300:300 DAR 1:1], 90k tbr, 90k tbn, 90k tbc
    
    Metadata:
    
      title           : 
    
      comment         : Other
    
Output #0, mp3, to 'pipe:':
    
  Metadata:
    
    TSRC            : AUUM71001516
    
    TIT2            : Sunlight
    
    TRCK            : 2
    
    TPE1            : Bag Raiders
    
    TCOP            : 2010 Modular Recordings
    
    TCON            : Electronic
    
    TALB            : Bag Raiders
    
    TPE2            : Bag Raiders
    
    TPOS            : 1/1
    
    TPUB            : Modular Recordings
    
    TCOM            : Chris Stracey/Jack Glass/Dan Black
    
    TDRL            : 2010
    
    TSSE            : Lavf55.48.101
    
    Stream #0:0: Audio: mp3 (libmp3lame), 44100 Hz, stereo, s16p, 192 kb/s
    
    Metadata:
    
      encoder         : Lavc55.69.100 libmp3lame
    
Stream mapping:
    
  Stream #0:0 -> #0:0 (mp3 (native) -> mp3 (libmp3lame))
    
size=       6kB time=00:00:00.21 bitrate= 227.6kbits/s    
    
size=     102kB time=00:00:04.31 bitrate= 193.7kbits/s    
    
size=     202kB time=00:00:08.56 bitrate= 192.9kbits/s    
    
size=     341kB time=00:00:14.49 bitrate= 192.5kbits/s    
    
size=     489kB time=00:00:20.82 bitrate= 192.4kbits/s    
    
size=     642kB time=00:00:27.35 bitrate= 192.3kbits/s    
    
size=     792kB time=00:00:33.75 bitrate= 192.2kbits/s    
    
size=     950kB time=00:00:40.49 bitrate= 192.2kbits/s    
    
size=    1106kB time=00:00:47.15 bitrate= 192.2kbits/s    
    
size=    1258kB time=00:00:53.63 bitrate= 192.1kbits/s    
    
size=    1415kB time=00:01:00.31 bitrate= 192.1kbits/s    
    
size=    1563kB time=00:01:06.66 bitrate= 192.1kbits/s    
    
size=    1710kB time=00:01:12.90 bitrate= 192.1kbits/s    
    
size=    1857kB time=00:01:19.17 bitrate= 192.1kbits/s    
    
size=    2008kB time=00:01:25.63 bitrate= 192.1kbits/s    
    
size=    2162kB time=00:01:32.21 bitrate= 192.1kbits/s    
    
size=    2299kB time=00:01:38.03 bitrate= 192.1kbits/s    
    
size=    2457kB time=00:01:44.80 bitrate= 192.1kbits/s    
    
size=    2600kB time=00:01:50.89 bitrate= 192.1kbits/s    
    
size=    2755kB time=00:01:57.52 bitrate= 192.1kbits/s    
    
size=    2864kB time=00:02:02.17 bitrate= 192.1kbits/s    
    
size=    3022kB time=00:02:08.88 bitrate= 192.1kbits/s    
    
size=    3172kB time=00:02:15.31 bitrate= 192.1kbits/s    
    
size=    3284kB time=00:02:20.06 bitrate= 192.1kbits/s    
    
size=    3385kB time=00:02:24.40 bitrate= 192.1kbits/s    
    
size=    3529kB time=00:02:30.51 bitrate= 192.0kbits/s    
    
size=    3687kB time=00:02:37.25 bitrate= 192.0kbits/s    
    
size=    3838kB time=00:02:43.71 bitrate= 192.0kbits/s    
    
size=    3988kB time=00:02:50.11 bitrate= 192.0kbits/s    
    
size=    4138kB time=00:02:56.53 bitrate= 192.0kbits/s    
    
size=    4279kB time=00:03:02.54 bitrate= 192.0kbits/s    
    
size=    4408kB time=00:03:08.03 bitrate= 192.0kbits/s    
    
size=    4544kB time=00:03:13.85 bitrate= 192.0kbits/s    
    
size=    4683kB time=00:03:19.78 bitrate= 192.0kbits/s    
    
size=    4805kB time=00:03:24.95 bitrate= 192.0kbits/s    
    
size=    4939kB time=00:03:30.67 bitrate= 192.0kbits/s    
    
size=    5049kB time=00:03:35.38 bitrate= 192.0kbits/s    
    
size=    5141kB time=00:03:39.32 bitrate= 192.0kbits/s    
    
size=    5263kB time=00:03:44.49 bitrate= 192.0kbits/s    
    
size=    5372kB time=00:03:49.17 bitrate= 192.0kbits/s    
    
The thread 0xb24 has exited with code 259 (0x103).
    
size=    5436kB time=00:03:51.91 bitrate= 192.0kbits/s    
    
size=    5509kB time=00:03:55.02 bitrate= 192.0kbits/s    
    
size=    5657kB time=00:04:01.32 bitrate= 192.0kbits/s    
    
size=    5702kB time=00:04:03.22 bitrate= 192.0kbits/s
    

    
video:0kB audio:5701kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.005738%

    Any ideas ? I’m grateful for suggestions - I’ve been chasing this for a week now !

  • Android ExoPlayer stream mp3 over HTTP

    8 juillet 2016, par kevintcoughlin

    I’m trying to get a grasp on the new ExoPlayer library introduced this year at Google I/O 2014 so that I can incorporate it into my application.

    I’m attempting to stream an mp3 over HTTP, but so far have been unsuccessful. I’m not sure if it’s possible, but I’m trying to accomplish this without extending any of the base Source/Sample classes. My code is as follows :

    In my Activity

    SampleSource s = new FrameworkSampleSource(this, Uri.parse("http://traffic.libsyn.com/joeroganexp/p518.mp3"), null, 1);
    

    
// Since I only have 1 audio renderer
    
ExoPlayer player = ExoPlayer.Factory.newInstance(1);
    

    
MediaCodecAudioTrackRenderer audioRenderer = new MediaCodecAudioTrackRenderer(s);
    
player.prepare(audioRenderer);
    
player.setPlayWhenReady(true);

    Logcat

    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ SniffFFMPEG
    
07-06 15:52:34.080    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ android-source:0xb7c53e00
    
07-06 15:52:34.084    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ android source begin open
    
07-06 15:52:34.084    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ android open, url: android-source:0xb7c53e00
    
07-06 15:52:34.084    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ ffmpeg open android data source success, source ptr: 0xb7c53e00
    
07-06 15:52:34.088    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ android source open success
    
07-06 15:52:34.108    3363-3363/com.kevintcoughlin.smodr W/EGL_genymotion﹕ eglSurfaceAttrib not implemented
    
07-06 15:52:34.116    3363-3363/com.kevintcoughlin.smodr E/OpenGLRenderer﹕ Getting MAX_TEXTURE_SIZE from GradienCache
    
07-06 15:52:34.120    3363-3363/com.kevintcoughlin.smodr E/OpenGLRenderer﹕ MAX_TEXTURE_SIZE: 16384
    
07-06 15:52:34.128    3363-3363/com.kevintcoughlin.smodr E/OpenGLRenderer﹕ Getting MAX_TEXTURE_SIZE from Caches::initConstraints()
    
07-06 15:52:34.128    3363-3363/com.kevintcoughlin.smodr E/OpenGLRenderer﹕ MAX_TEXTURE_SIZE: 16384
    
07-06 15:52:34.128    3363-3363/com.kevintcoughlin.smodr D/OpenGLRenderer﹕ Enabling debug mode 0
    
07-06 15:52:34.640    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ [mp3 @ 0xb7c57040] Estimating duration from bitrate, this may be inaccurate
    
07-06 15:52:34.640    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ Input #0, mp3, from 'android-source:0xb7c53e00':
    
07-06 15:52:34.640    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ Metadata:
    
07-06 15:52:34.640    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ TSS             : Logic Pro 9.1.8
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ title           : #518 - Matt Fulchiron
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ artist          : Joe Rogan Experience
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ album_artist    : Joe Rogan Experience
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ Duration: 02:57:10.21, start: 0.000000, bitrate: 127 kb/s
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ FFmpegExtrator, url: android-source:0xb7c53e00, format_name: mp3, format_long_name: MP2/3 (MPEG audio layer 2/3)
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ list the formats suppoted by ffmpeg:
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ ========================================
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[00]: mpeg
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[01]: mpegts
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[02]: mov,mp4,m4a,3gp,3g2,mj2
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[03]: matroska,webm
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[04]: asf
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[05]: rm
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[06]: flv
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[07]: swf
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[08]: avi
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[09]: ape
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[10]: dts
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[11]: flac
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[12]: ac3
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[13]: wav
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[14]: ogg
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[15]: vc1
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[16]: hevc
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ ========================================
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ android source close
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr W/FFmpegExtractor﹕ sniff through BetterSniffFFMPEG failed, try LegacySniffFFMPEG
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ source url:http://traffic.libsyn.com/joeroganexp/p518.mp3
    
07-06 15:52:34.644    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ android source begin open
    
07-06 15:52:34.648    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ android open, url: android-source:0xb7c53e00|file:http://traffic.libsyn.com/joeroganexp/p518.mp3
    
07-06 15:52:34.648    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ ffmpeg open android data source success, source ptr: 0xb7c53e00
    
07-06 15:52:34.648    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ android source open success
    
07-06 15:52:34.708    3363-3394/com.kevintcoughlin.smodr D/dalvikvm﹕ GC_FOR_ALLOC freed 361K, 4% free 10852K/11288K, paused 75ms, total 75ms
    
07-06 15:52:34.844    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ [mp3 @ 0xb7ca7700] Estimating duration from bitrate, this may be inaccurate
    
07-06 15:52:34.844    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ Input #0, mp3, from 'android-source:0xb7c53e00|file:http://traffic.libsyn.com/joeroganexp/p518.mp3':
    
07-06 15:52:34.844    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ Metadata:
    
07-06 15:52:34.844    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ TSS             : Logic Pro 9.1.8
    
07-06 15:52:34.848    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ title           : #518 - Matt Fulchiron
    
07-06 15:52:34.848    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ artist          : Joe Rogan Experience
    
07-06 15:52:34.848    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ album_artist    : Joe Rogan Experience
    
07-06 15:52:34.848    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ Duration: 02:57:10.21, start: 0.000000, bitrate: 127 kb/s
    
07-06 15:52:34.848    3363-3376/com.kevintcoughlin.smodr I/FFMPEG﹕ Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s
    
07-06 15:52:34.848    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ FFmpegExtrator, url: android-source:0xb7c53e00|file:http://traffic.libsyn.com/joeroganexp/p518.mp3, format_name: mp3, format_long_name: MP2/3 (MPEG audio layer 2/3)
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ list the formats suppoted by ffmpeg:
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ ========================================
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[00]: mpeg
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[01]: mpegts
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[02]: mov,mp4,m4a,3gp,3g2,mj2
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[03]: matroska,webm
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[04]: asf
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[05]: rm
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[06]: flv
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[07]: swf
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[08]: avi
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[09]: ape
    
07-06 15:52:34.852    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[10]: dts
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[11]: flac
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[12]: ac3
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[13]: wav
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[14]: ogg
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[15]: vc1
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr V/FFmpegExtractor﹕ format_names[16]: hevc
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr I/FFmpegExtractor﹕ ========================================
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr D/FFMPEG﹕ android source close
    
07-06 15:52:34.856    3363-3376/com.kevintcoughlin.smodr D/FFmpegExtractor﹕ SniffFFMPEG failed to sniff this source
    
07-06 15:52:34.856    3363-3397/com.kevintcoughlin.smodr D/dalvikvm﹕ GC_FOR_ALLOC freed 120K, 3% free 12342K/12696K, paused 29ms, total 60ms
    
07-06 15:52:34.860    3363-3397/com.kevintcoughlin.smodr I/dalvikvm-heap﹕ Grow heap (frag case) to 13.981MB for 1960012-byte allocation
    
07-06 15:52:34.872    3363-3387/com.kevintcoughlin.smodr D/dalvikvm﹕ GC_FOR_ALLOC freed <1K, 3% free 14256K/14612K, paused 10ms, total 10ms
    
07-06 15:52:34.880    3363-3376/com.kevintcoughlin.smodr I/OMXClient﹕ Using client-side OMX mux.
    
07-06 15:52:34.976    3363-3400/com.kevintcoughlin.smodr I/OMXClient﹕ Using client-side OMX mux.
    
07-06 15:52:35.144    3363-3393/com.kevintcoughlin.smodr D/dalvikvm﹕ GC_FOR_ALLOC freed 1512K, 12% free 13705K/15532K, paused 12ms, total 36ms
    
07-06 15:52:35.152    3363-3393/com.kevintcoughlin.smodr I/dalvikvm-heap﹕ Grow heap (frag case) to 15.315MB for 1962812-byte allocation
    
07-06 15:52:35.200    3363-3388/com.kevintcoughlin.smodr D/dalvikvm﹕ GC_FOR_ALLOC freed <1K, 11% free 15621K/17452K, paused 39ms, total 39ms
    
07-06 15:52:35.356    3363-3400/com.kevintcoughlin.smodr E/ACodec﹕ OMX/mediaserver died, signalling error!
    
07-06 15:52:35.356    3363-3400/com.kevintcoughlin.smodr E/MediaCodec﹕ Codec reported an error. (omx error 0x8000100d, internalError -32)
    
07-06 15:52:35.376    3363-3400/com.kevintcoughlin.smodr A/ACodec﹕ frameworks/av/media/libstagefright/ACodec.cpp:499 CHECK(mem.get() != NULL) failed.
    
07-06 15:52:35.376    3363-3400/com.kevintcoughlin.smodr A/libc﹕ Fatal signal 4 (SIGILL) at 0xb76d563d (code=2), thread 3400 (MediaCodec_loop)

    To my untrained eye it seems like I can get the TrackInfo correctly, but am having a problem reading the data over HTTP. It also seems that how the framework sniffs the mimetype is failing even though I do receive type ’audio/mpeg’.

    Again, I appreciate any direction I receive. I realize that these APIs are very new.

    Thanks !

  • Reverse Engineering Italian Literature

    1er juillet 2014, par Multimedia Mike — Reverse Engineering

    Some time ago, Diego “Flameeyes” Pettenò tried his hand at reverse engineering a set of really old CD-ROMs containing even older Italian literature. The goal of this RE endeavor would be to extract the useful literature along with any structural metadata (chapters, etc.) and convert it to a more open format suitable for publication at, e.g., Project Gutenberg or Archive.org.

    Unfortunately, the structure of the data thwarted the more simplistic analysis attempts (like inspecting for blocks of textual data). This will require deeper RE techniques. Further frustrating the effort, however, is the fact that the binaries that implement the reading program are written for the now-archaic Windows 3.1 operating system.

    In pursuit of this RE goal, I recently thought of a way to glean more intelligence using DOSBox.

    Prior Work
    There are 6 discs in the full set (distributed along with 6 sequential issues of a print magazine named L’Espresso). Analysis of the contents of the various discs reveals that many of the files are the same on each disc. It was straightforward to identify the set of files which are unique on each disc. This set of files all end with the extension “LZn”, where n = 1..6 depending on the disc number. Further, the root directory of each disc has a file indicating the sequence number (1..6) of the CD. Obviously, these are the interesting targets.

    The LZ file extensions stand out to an individual skilled in the art of compression– could it be a variation of the venerable LZ compression ? That’s actually unlikely because LZ — also seen as LIZ — stands for Letteratura Italiana Zanichelli (Zanichelli’s Italian Literature).

    The Unix ‘file’ command was of limited utility, unable to plausibly identify any of the files.

    Progress was stalled.

    Saying Hello To An Old Frenemy
    I have been showing this screenshot to younger coworkers to see if any of them recognize it :


    DOSBox running Window 3.1

    Not a single one has seen it before. Senior computer citizen status : Confirmed.

    I recently watched an Ancient DOS Games video about Windows 3.1 games. This episode showed Windows 3.1 running under DOSBox. I had heard this was possible but that it took a little work to get running. I had a hunch that someone else had probably already done the hard stuff so I took to the BitTorrent networks and quickly found a download that had the goods ready to go– a directory of Windows 3.1 files that just had to be dropped into a DOSBox directory and they would be ready to run.

    Aside : Running OS software procured from a BitTorrent network ? Isn’t that an insane security nightmare ? I’m not too worried since it effectively runs under a sandboxed virtual machine, courtesy of DOSBox. I suppose there’s the risk of trojan’d OS software infecting binaries that eventually leave the sandbox.

    Using DOSBox Like ‘strace’
    strace is a tool available on some Unix systems, including Linux, which is able to monitor the system calls that a program makes. In reverse engineering contexts, it can be useful to monitor an opaque, binary program to see the names of the files it opens and how many bytes it reads, and from which locations. I have written examples of this before (wow, almost 10 years ago to the day ; now I feel old for the second time in this post).

    Here’s the pitch : Make DOSBox perform as strace in order to serve as a platform for reverse engineering Windows 3.1 applications. I formed a mental model about how DOSBox operates — abstracted file system classes with methods for opening and reading files — and then jumped into the source code. Sure enough, the code was exactly as I suspected and a few strategic print statements gave me the data I was looking for.

    Eventually, I even took to running DOSBox under the GNU Debugger (GDB). This hasn’t proven especially useful yet, but it has led to an absurd level of nesting :


    GDB runs DOSBox runs Windows 3.1

    The target application runs under Windows 3.1, which is running under DOSBox, which is running under GDB. This led to a crazy situation in which DOSBox had the mouse focus when a GDB breakpoint was triggered. At this point, DOSBox had all desktop input focus and couldn’t surrender it because it wasn’t running. I had no way to interact with the Linux desktop and had to reboot the computer. The next time, I took care to only use the keyboard to navigate the application and trigger the breakpoint and not allow DOSBox to consume the mouse focus.

    New Intelligence

    By instrumenting the local file class (virtual HD files) and the ISO file class (CD-ROM files), I was able to watch which programs and dynamic libraries are loaded and which data files the code cares about. I was able to narrow down the fact that the most interesting programs are called LEGGENDO.EXE (‘reading’) and LEGGENDA.EXE (‘legend’ ; this has been a great Italian lesson as well as RE puzzle). The first calls the latter, which displays this view of the data we are trying to get at :


    LIZ: Authors index

    When first run, the program takes an interest in a file called DBBIBLIO (‘database library’, I suspect) :

    === Read(’LIZ98\DBBIBLIO.LZ1’) : req 337 bytes ; read 337 bytes from pos 0x0
=== Read(’LIZ98\DBBIBLIO.LZ1’) : req 337 bytes ; read 337 bytes from pos 0x151
=== Read(’LIZ98\DBBIBLIO.LZ1’) : req 337 bytes ; read 337 bytes from pos 0x2A2
[...]

    While we were unable to sort out all of the data files in our cursory investigation, a few things were obvious. The structure of this file looked to contain 336-byte records. Turns out I was off by 1– the records are actually 337 bytes each. The count of records read from disc is equal to the number of items shown in the UI.

    Next, the program is interested in a few more files :

    *** isoFile() : ’DEPOSITO\BLOKCTC.LZ1’, offset 0x27D6000, 2911488 bytes large
=== Read(’DEPOSITO\BLOKCTC.LZ1’) : req 96 bytes ; read 96 bytes from pos 0x0
*** isoFile() : ’DEPOSITO\BLOKCTX0.LZ1’, offset 0x2A9D000, 17152 bytes large
=== Read(’DEPOSITO\BLOKCTX0.LZ1’) : req 128 bytes ; read 128 bytes from pos 0x0
=== Seek(’DEPOSITO\BLOKCTX0.LZ1’) : seek 384 (0x180) bytes, type 0
=== Read(’DEPOSITO\BLOKCTX0.LZ1’) : req 256 bytes ; read 256 bytes from pos 0x180
=== Seek(’DEPOSITO\BLOKCTC.LZ1’) : seek 1152 (0x480) bytes, type 0
=== Read(’DEPOSITO\BLOKCTC.LZ1’) : req 32 bytes ; read 32 bytes from pos 0x480
=== Read(’DEPOSITO\BLOKCTC.LZ1’) : req 1504 bytes ; read 1504 bytes from pos 0x4A0
[...]

    Eventually, it becomes obvious that BLOKCTC has the juicy meat. There are 32-byte records followed by variable-length encoded text sections. Since there is no text to be found in these files, the text is either compressed, encrypted, or both. Some rough counting (the program seems to disable copy/paste, which thwarts more precise counting), indicates that the text size is larger than the data chunks being read from disc, so compression seems likely. Encryption isn’t out of the question (especially since the program deems it necessary to disable copy and pasting of this public domain literary data), and if it’s in use, that means the key is being read from one of these files.

    Blocked On Disassembly
    So I’m a bit blocked right now. I know exactly where the data lives, but it’s clear that I need to reverse engineer some binary code. The big problem is that I have no idea how to disassemble Windows 3.1 binaries. These are NE-type executable files. Disassemblers abound for MZ files (MS-DOS executables) and PE files (executables for Windows 95 and beyond). NE files get no respect. It’s difficult (but not impossible) to even find data about the format anymore, and details are incomplete. It should be noted, however, the DOSBox-as-strace method described here lends insight into how Windows 3.1 processes NE-type EXEs. You can’t get any more authoritative than that.

    So far, I have tried the freeware version of IDA Pro. Unfortunately, I haven’t been able to get the program to work on my Windows machine for a long time. Even if I could, I can’t find any evidence that it actually supports NE files (the free version specifically mentions MZ and PE, but does not mention NE or LE).

    I found an old copy of Borland’s beloved Turbo Assembler and Debugger package. It has Turbo Debugger for Windows, both regular and 32-bit versions. Unfortunately, the normal version just hangs Windows 3.1 in DOSBox. The 32-bit Turbo Debugger loads just fine but can’t load the NE file.

    I’ve also wondered if DOSBox contains any advanced features for trapping program execution and disassembling. I haven’t looked too deeply into this yet.

    Future Work
    NE files seem to be the executable format that time forgot. I have a crazy brainstorm about repacking NE files as MZ executables so that they could be taken apart with an MZ disassembler. But this will take some experimenting.

    If anyone else has any ideas about ripping open these binaries, I would appreciate hearing them.

    And I guess I shouldn’t be too surprised to learn that all the literature in this corpus is already freely available and easily downloadable anyway. But you shouldn’t be too surprised if that doesn’t discourage me from trying to crack the format that’s keeping this particular copy of the data locked up.

Navigation