Recherche avancée

Sur d’autres sites (7927)

• Alias Artifacts

  26 avril 2013, par Multimedia Mike — General

  Throughout my own life, I have often observed that my own sense of nostalgia has a window that stretches about 10-15 years past from the current moment. Earlier this year, I discovered the show “Alias” and watched through the entire series thanks to Amazon Prime Instant Video (to be fair, I sort of skimmed the fifth and final season which I found to be horribly dull, or maybe franchise fatigue had set in). The show originally aired from 2001-2006 so I found that it fit well within the aforementioned nostalgia window.

  
  
  

  But what was it, exactly, about the show that triggered nostalgia ? The computers, of course ! The show revolved around spies and espionage and cutting-edge technology necessarily played a role. The production designer for the series must have decided that Unix/Linux == awesome hacking and so many screenshots featured Linux.

  Since this is still nominally a multimedia blog, I’ll start of the screenshot recon with an old multimedia player. Here is a vintage Mac OS desktop running an ancient web browser (probably Netscape) that’s playing a full-window video (probably QuickTime embedded directly into the browser).

  
  

  

  Click for larger image

  
  

  Let’s jump right into the Linux side of things. This screenshot makes me particularly sentimental since this is exactly what a stock Linux/KDE desktop looked like circa 2001-2003 and is more or less what I would have worked with on my home computer at the time :

  
  

  

  Click for larger image

  
  

  Studying that screenshot, we see that the user logs in as root, even to the desktop environment. Poor security practice ; I would expect better from a bunch of spooks.

  Echelon
  Look at the terminal output in the above screenshot– it’s building a program named Echelon, an omniscient spy tool inspired by a real-world surveillance network of the same name. In the show, Echelon is used to supply plot-convenient intelligence. At one point, some antagonists get their hands on the Echelon source code and seek to compile it. When they do, they will have access to the vast surveillance network. If you know anything about how computers work, don’t think about that too hard.

  Anyway, it’s interesting to note that Echelon is a properly autotool’d program– when the bad guys finally got Echelon, installation was just a ‘make install’ command away. The compilation was very user-friendly, though, as it would pop up a nice dialog box showing build progress :

  
  

  

  Click for larger image

  
  

  Examining the build lines in both that screenshot and the following lines, we can see that Echelon cares about files such as common/db_err.c and bt_curadj.c :

  
  

  

  Click for larger image

  
  

  A little googling reveals that these files both belong to the Berkeley DB library. That works ; I can imagine a program like this leveraging various database packages.

  Computer Languages
  The Echelon source code stuff comes from episode 2.11 : “A Higher Echelon”. While one faction had gotten a hold of the actual Echelon source code, a rival faction had abducted the show’s resident uber-nerd and, learning that they didn’t actually receive the Echelon code, force the nerd to re-write Echelon from scratch. Which he then proceeds to do…

  
  

  

  Click for larger image

  
  

  The code he’s examining there appears to be C code that has something to do with joystick programming (JS_X_0, JS_Y_1, etc.). An eagle-eyed IMDb user contributed the trivia that he is looking at the file /usr/include/Linux/joystick.h.

  Getting back to the plot, how could the bad buys possibly expect him to re-write a hugely complex piece of software from scratch ? You might think this is the height of absurdity for a computer-oriented story. You’ll be pleased to know that the writers agreed with that assessment since, when the program was actually executed, it claimed to be Echelon, but that broke into a game of Pong (or some simple game). Suddenly, it makes perfect sense why the guy was looking at the joystick header file.

  This is the first bit of computer-oriented fun that I captured when I was watching the series :

  
  

  

  Click for larger image

  
  

  This printout purports to be a “mainframe log summary”. After some plot-advancing text about a security issue, it proceeds to dump out some Java source code.

  SSH
  Secure Shell (SSH) frequently showed up. Here’s a screenshot in which a verbose ‘ssh -v’ connection has just been closed, while a telnet command has apparently just been launched (evidenced by “Escape character is ‘^]’.”) :

  
  

  

  Click for larger image

  
  

  This is followed by some good old Hollywood Hacking in which a free-form database command is entered through any available command line interface :

  
  

  

  Click for larger image

  
  

  I don’t remember the episode details, but I’m pretty sure the output made perfect sense to the character typing the command. Here’s another screenshot where the SSH client pops up an extra-large GUI dialog element to notify the user that it’s currently negotiating with the host :

  
  

  

  Click for larger image

  
  

  Now that I look at that screenshot a little more closely, it appears to be a Win95/98 program. I wonder if there was an SSH client that actually popped up that gaudy dialog.

  There’s a lot of gibberish in this screenshot and I wish I had written down some details about what it represented according to the episode’s plot :

  
  

  

  Click for larger image

  
  

  It almost sounds like they were trying to break into a network computer. Analyzing MD5 structure… public key synthesized. To me, the funniest feature is the 7-digit public key. I’m a bit rusty on the math of the RSA cryptosystem, but intuitively, it seems that the public and private keys need to be of roughly equal lengths. I.e., the private key in this scenario would also be 7 digits long.

  Gadgets
  Various devices and gadgets were seen at various junctures in the show. Here’s a tablet computer from back when tablet computers seemed like fantastical (albeit stylus-requiring) devices– the Fujitsu Stylistic 2300 :

  
  

  

  Click for larger image

  
  

  Here’s a videophone from an episode that aired in 2005. The specific model is the Packet8 DV326 (MSRP of US$500). As you can see from the screenshot, it can do 384 kbps both down and up.

  
  

  

  Click for larger image

  
  

  I really regret not writing down the episode details surrounding this gadget. I just know that it was critical that the good guys get it and keep from falling into the hands of the bad guys.

  
  

  

  Click for larger image

  
  

  As you can see, the (presumably) deadly device contains a Samsung chip and a Lexar chip. I have to wonder what device the production crew salvaged this from (probably just an old cell phone).

  Other Programs

  The GIMP photo editor makes an appearance while scrubbing security camera footage, and serves as the magical Enhance Button (at least they slung around the term “gamma”) :

  
  

  

  Click for larger image

  
  

  I have no idea what MacOS-based audio editing program this is. Any ideas ?

  
  

  

  Click for larger image

  
  

  FTP shows up in episode 2.12, “The Getaway”. It’s described as a “secure channel” for communication, which is quite humorous to anyone versed in internet technology.

  
  

  

  Click for larger image

  
  

• battery performance of vlc player on android

  7 juillet 2013, par rajneesh

  i want to support custom video file-format to be played on android.
  for the purpose i want to modify the vlc player for android, but i am concerned that vlc might be doing "software video decoding" and which might have impact on battery life.

  I want to understand the following

  1. Is there any battery life comparison between software and hardware decoding of video codecs.
  2. does vlc on android make use of hardware decoder.if available on phone ?
  3. does file format have any impact on the selection of hardware or software decoder

• libavcodec/libx264 do not produce B-frames

  6 novembre 2013, par Rob Schmidt

  I am writing an application in C++ that uses libavcodec with libx264 to encode video. However, the encoded data ended up being much larger than I expected. I analyzed the results and discovered that my encoding never produced B-frames, only I- and P-frames.

  I created a standalone utility based on the ffmpeg source code and examples to test my encoder setup. It reads in an H.264 file, re-encodes the decoded frames, and outputs the result to a file using the ITU H.264 Annex B format. I also used ffmpeg to perform the same operation so I could compare against a known good implementation. My utility never outputs B-frames whereas ffmpeg does.

  I have since tried to figure out what ffmpeg does that my code doesn’t. I first tried manually specifying encoder settings related to B-frames. This had no effect.

  I then tried running both ffmpeg and my utility under gdb and comparing the contents of the AVStream, AVCodecContext, and X264Context prior to opening the encoder and manually setting any fields that appeared different. Even with identical settings, I still only produce I- and P-frames.

  Finally, I thought that perhaps the problem was with my timestamp handling. I reworked my test utility to mimic the pipeline used by ffmpeg and to output timestamp debugging output like ffmpeg does. Even with my timestamps identical to ffmpeg’s I still get no B-frames.

  At this point I don’t know what else to try. When I run ffmpeg, I run it with the command line below. Note that aside from the "superfast" preset, I pretty much use the default values.

  ffmpeg -v debug -i ~/annexb.264 -codec:v libx264 -preset superfast -g 30 -f h264 ./out.264

  The code that configures the encoder is listed below. It specifies the "superfast" preset too.

  static AVStream *add_video_stream(AVFormatContext *output_ctx, AVCodec **output_codec, enum AVCodecID codec_id)
  
  {
  
      *output_codec = avcodec_find_encoder(codec_id);
  
      if (*output_codec == NULL) {
  
          printf("Could not find encoder for '%s' (%d)\n", avcodec_get_name(codec_id), codec_id);
  
          return NULL;
  
      }
  
  
  
      AVStream *output_stream = avformat_new_stream(output_ctx, *output_codec);
  
      if (output_stream == NULL) {
  
          printf("Could not create video stream.\n");
  
          return NULL;
  
      }
  
      output_stream->id = output_ctx->nb_streams - 1;
  
      AVCodecContext *codec_ctx = output_stream->codec;
  
  
  
      avcodec_get_context_defaults3(codec_ctx, *output_codec);
  
  
  
      codec_ctx->width = 1280;
  
      codec_ctx->height = 720;
  
  
  
      codec_ctx->time_base.den = 15000;
  
      codec_ctx->time_base.num = 1001;
  
  
  
  /*    codec_ctx->gop_size = 30;*/
  
      codec_ctx->pix_fmt = AV_PIX_FMT_YUVJ420P;
  
  
  
      // try to force B-frame output
  
  /*    codec_ctx->max_b_frames = 3;*/
  
  /*    codec_ctx->b_frame_strategy = 2;*/
  
  
  
      output_stream->sample_aspect_ratio.num = 1;
  
      output_stream->sample_aspect_ratio.den = 1;
  
  
  
      codec_ctx->sample_aspect_ratio.num = 1;
  
      codec_ctx->sample_aspect_ratio.den = 1;
  
  
  
      codec_ctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
  
  
  
      codec_ctx->bits_per_raw_sample = 8;
  
  
  
      if ((output_ctx->oformat->flags & AVFMT_GLOBALHEADER) != 0) {
  
          codec_ctx->flags |= CODEC_FLAG_GLOBAL_HEADER;
  
      }
  
  
  
      return output_stream;
  
  }
  
  
  
  
  
  int main(int argc, char **argv)
  
  {
  
      // ... open input file 
  
  
  
      avformat_alloc_output_context2(&output_ctx, NULL, "h264", output_path);
  
      if (output_ctx == NULL) {
  
          fprintf(stderr, "Unable to allocate output context.\n");
  
          return 1;
  
      } 
  
  
  
      AVCodec *output_codec = NULL;
  
      output_stream = add_video_stream(output_ctx, &output_codec, output_ctx->oformat->video_codec);
  
      if (output_stream == NULL) {
  
          fprintf(stderr, "Error adding video stream to output context.\n");
  
          return 1;
  
      }
  
      encode_ctx = output_stream->codec;
  
  
  
      // seems to have no effect
  
  #if 0
  
      if (decode_ctx->extradata_size != 0) {
  
          size_t extradata_size = decode_ctx->extradata_size;
  
          printf("extradata_size: %zu\n", extradata_size);
  
          encode_ctx->extradata = av_mallocz(extradata_size + FF_INPUT_BUFFER_PADDING_SIZE);
  
          memcpy(encode_ctx->extradata, decode_ctx->extradata, extradata_size);
  
          encode_ctx->extradata_size = extradata_size;
  
      }
  
  #endif // 0
  
  
  
      AVDictionary *opts = NULL;
  
      av_dict_set(&opts, "preset", "superfast", 0);
  
      // av_dict_set(&opts, "threads", "auto", 0); // seems to have no effect
  
  
  
      ret = avcodec_open2(encode_ctx, output_codec, &opts);
  
      if (ret < 0) {
  
          fprintf(stderr, "Unable to open output video cocec: %s\n", av_err2str(ret));
  
          return 1;
  
      }
  
  
  
      // ... decoding/encoding loop, clean up, etc.
  
  
  
      return 0;
  
  }

  My test utility produces the following debug output in which you can see there are no B-frames produced :

  [libx264 @ 0x1b8c9c0] using mv_range_thread = 56
  
  [libx264 @ 0x1b8c9c0] using SAR=1/1
  
  [libx264 @ 0x1b8c9c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
  
  [libx264 @ 0x1b8c9c0] profile High, level 3.1
  
  Output #0, h264, to './out.264':
  
      Stream #0:0, 0, 1/90000: Video: h264, yuvj420p, 1280x720 [SAR 1:1 DAR 16:9], 1001/15000, q=-1--1, 90k tbn, 14.99 tbc
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x1b8c9c0] frame=   0 QP=17.22 NAL=3 Slice:I Poc:0   I:3600 P:0    SKIP:0    size=122837 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   1 QP=18.03 NAL=2 Slice:P Poc:2   I:411  P:1825 SKIP:1364 size=25863 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   2 QP=17.03 NAL=2 Slice:P Poc:4   I:369  P:2159 SKIP:1072 size=37880 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   3 QP=16.90 NAL=2 Slice:P Poc:6   I:498  P:2330 SKIP:772  size=50509 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   4 QP=16.68 NAL=2 Slice:P Poc:8   I:504  P:2233 SKIP:863  size=50791 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   5 QP=16.52 NAL=2 Slice:P Poc:10  I:513  P:2286 SKIP:801  size=51820 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   6 QP=16.49 NAL=2 Slice:P Poc:12  I:461  P:2293 SKIP:846  size=51311 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   7 QP=16.65 NAL=2 Slice:P Poc:14  I:476  P:2287 SKIP:837  size=51196 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   8 QP=16.66 NAL=2 Slice:P Poc:16  I:508  P:2240 SKIP:852  size=51577 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   9 QP=16.55 NAL=2 Slice:P Poc:18  I:477  P:2278 SKIP:845  size=51531 bytes
  
  [libx264 @ 0x1b8c9c0] frame=  10 QP=16.67 NAL=2 Slice:P Poc:20  I:517  P:2233 SKIP:850  size=51946 bytes
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x1b8c9c0] frame I:7     Avg QP:13.71  size:152207
  
  [libx264 @ 0x1b8c9c0] frame P:190   Avg QP:16.66  size: 50949
  
  [libx264 @ 0x1b8c9c0] mb I  I16..4: 27.1% 30.8% 42.1%
  
  [libx264 @ 0x1b8c9c0] mb P  I16..4:  6.8%  6.0%  0.8%  P16..4: 61.8%  0.0%  0.0%  0.0%  0.0%    skip:24.7%
  
  [libx264 @ 0x1b8c9c0] 8x8 transform intra:41.2% inter:86.9%
  
  [libx264 @ 0x1b8c9c0] coded y,uvDC,uvAC intra: 92.2% 28.3% 5.4% inter: 50.3% 1.9% 0.0%
  
  [libx264 @ 0x1b8c9c0] i16 v,h,dc,p:  7%  7% 77%  8%
  
  [libx264 @ 0x1b8c9c0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  7% 15% 49%  6%  4%  3%  5%  3%  8%
  
  [libx264 @ 0x1b8c9c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 25% 24%  6%  7%  4%  6%  3%  6%
  
  [libx264 @ 0x1b8c9c0] i8c dc,h,v,p: 72% 14% 10%  4%
  
  [libx264 @ 0x1b8c9c0] Weighted P-Frames: Y:0.0% UV:0.0%
  
  [libx264 @ 0x1b8c9c0] kb/s:6539.11
  
  </snip></snip>

  ffmpeg, on the other hand, produces the following output that is almost identical but includes B-frames :

  [libx264 @ 0x20b9c40] using mv_range_thread = 56
  
  [libx264 @ 0x20b9c40] using SAR=1/1
  
  [libx264 @ 0x20b9c40] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
  
  [libx264 @ 0x20b9c40] profile High, level 3.1
  
  [h264 @ 0x20b8160] detected 4 logical cores
  
  Output #0, h264, to './out.264':
  
    Metadata:
  
      encoder         : Lavf54.63.104
  
      Stream #0:0, 0, 1/90000: Video: h264, yuvj420p, 1280x720 [SAR 1:1 DAR 16:9], 1001/15000, q=-1--1, 90k tbn, 14.99 tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (h264 -> libx264)
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x20b9c40] frame=   0 QP=17.22 NAL=3 Slice:I Poc:0   I:3600 P:0    SKIP:0    size=122835 bytes
  
  [libx264 @ 0x20b9c40] frame=   1 QP=18.75 NAL=2 Slice:P Poc:8   I:984  P:2045 SKIP:571  size=54208 bytes
  
  [libx264 @ 0x20b9c40] frame=   2 QP=19.40 NAL=2 Slice:B Poc:4   I:447  P:1581 SKIP:1572 size=24930 bytes
  
  [libx264 @ 0x20b9c40] frame=   3 QP=19.78 NAL=0 Slice:B Poc:2   I:199  P:1002 SKIP:2399 size=10717 bytes
  
  [libx264 @ 0x20b9c40] frame=   4 QP=20.19 NAL=0 Slice:B Poc:6   I:204  P:1155 SKIP:2241 size=15937 bytes
  
  [libx264 @ 0x20b9c40] frame=   5 QP=18.11 NAL=2 Slice:P Poc:16  I:990  P:2221 SKIP:389  size=64240 bytes
  
  [libx264 @ 0x20b9c40] frame=   6 QP=19.35 NAL=2 Slice:B Poc:12  I:439  P:1784 SKIP:1377 size=34048 bytes
  
  [libx264 @ 0x20b9c40] frame=   7 QP=19.88 NAL=0 Slice:B Poc:10  I:275  P:1035 SKIP:2290 size=16911 bytes
  
  [libx264 @ 0x20b9c40] frame=   8 QP=19.91 NAL=0 Slice:B Poc:14  I:257  P:1270 SKIP:2073 size=19172 bytes
  
  [libx264 @ 0x20b9c40] frame=   9 QP=17.90 NAL=2 Slice:P Poc:24  I:962  P:2204 SKIP:434  size=67439 bytes
  
  [libx264 @ 0x20b9c40] frame=  10 QP=18.84 NAL=2 Slice:B Poc:20  I:474  P:1911 SKIP:1215 size=37742 bytes
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x20b9c40] frame I:7     Avg QP:15.95  size:130124
  
  [libx264 @ 0x20b9c40] frame P:52    Avg QP:17.78  size: 64787
  
  [libx264 @ 0x20b9c40] frame B:138   Avg QP:19.32  size: 26231
  
  [libx264 @ 0x20b9c40] consecutive B-frames:  6.6%  0.0%  0.0% 93.4%
  
  [libx264 @ 0x20b9c40] mb I  I16..4: 30.2% 35.2% 34.6%
  
  [libx264 @ 0x20b9c40] mb P  I16..4: 13.9% 11.4%  0.3%  P16..4: 60.4%  0.0%  0.0%  0.0%  0.0%    skip:13.9%
  
  [libx264 @ 0x20b9c40] mb B  I16..4:  5.7%  3.3%  0.0%  B16..8: 15.8%  0.0%  0.0%  direct:25.7%  skip:49.5%  L0:43.2% L1:37.3% BI:19.5%
  
  [libx264 @ 0x20b9c40] 8x8 transform intra:39.4% inter:77.2%
  
  [libx264 @ 0x20b9c40] coded y,uvDC,uvAC intra: 90.7% 26.6% 3.0% inter: 34.0% 4.1% 0.0%
  
  [libx264 @ 0x20b9c40] i16 v,h,dc,p:  7%  7% 77%  9%
  
  [libx264 @ 0x20b9c40] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  7% 16% 51%  5%  4%  3%  5%  3%  7%
  
  [libx264 @ 0x20b9c40] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 27% 20%  6%  6%  3%  6%  3%  6%
  
  [libx264 @ 0x20b9c40] i8c dc,h,v,p: 71% 15% 11%  3%
  
  [libx264 @ 0x20b9c40] Weighted P-Frames: Y:0.0% UV:0.0%
  
  [libx264 @ 0x20b9c40] kb/s:4807.16
  
  </snip></snip>

  I’m sure I’m missing something simple, but I can’t for the life of me see what it is. Any assistance would be greatly appreciated.