Recherche avancée

Sur d’autres sites (5041)

• Optical Drive Value Proposition

  28 août 2010, par Multimedia Mike — General

  I have the absolute worst luck in the optical drive department. Ever since I started building my own computers in 1995 — close to the beginning of the CD-ROM epoch — I have burned through a staggering number of optical drives. Seriously, especially in the time period between about 1995-1998, I was going through a new drive every 4-6 months or so. This was also during that CD-ROM speed race where the the drive packages kept advertising loftier ‘X’ speed ratings. I didn’t play a lot of CD-ROM games during that timeframe, though I did listen to quite a few audio CDs through the computer.

  
  
  

  I use “optical drive” as a general term to describe CD-ROM drives, CD-R/RW drives, DVD-ROM drives, DVD-R/RW drives, and drives capable of doing any combination of reading and writing CDs and DVDs. In my observation, optical media seems to be falling out of favor somewhat, giving way to online digital distribution for things like games and software, as well as flash drives and external hard drives vs. recordable or rewritable media for backup and sneakernet duty. Somewhere along the line, I started to buy computers that didn’t even have optical drives. That’s why I have purchased at least 2 external USB drives (seen in the picture above). I don’t have much confidence that either works correctly. My main desktop until recently, a Mac Mini, has an internal optical drive that grew flaky and unreliable a few months after the unit was purchased.

  I just have really rotten luck with optical drives. The most reliable drive in my house is the one on the headless machine that, until recently, was the main workhorse on the FATE farm. The eject switch didn’t work correctly so I have to log in remotely, 'sudo eject', walk to the other room, pop in the disc, walk back to the other room, and work with the disc.

  Maybe optical media is on its way out, but I still have many hundreds of CD-ROMs. Perhaps I should move forward on this brainstorm to archive all of my optical discs on hard drives (and then think of some data mining experiments, just for the academic appeal), before it’s too late ; optical discs don’t last forever.

  So if I needed a good optical drive, what should I consider ? I’ve always been the type to go cheap, I admit. Many of my optical drives were on the lower end of the cost spectrum, which might have played some role in their rapid replacement. However, I’m not sold on the idea that I’m getting quality just because I’m paying a higher price. That LG unit at the top of the pile up there was relatively pricey and still didn’t fare well in the long (or even medium) term.

  Come to think of it, I used to have a ridiculous stockpile of castoff (but somehow still functional) optical drives. So many, in fact, that in 2004 I had a full size PC tower that I filled with 4 working drives, just because I could. Okay, I admit that there was a period where I had some reliable drives.

  That might be an idea, actually– throw together such a computer for heavy duty archival purposes. I visited Weird Stuff Warehouse today (needed some PC100 RAM for an old machine and they came through) and I think I could put together such a box rather cheaply.

  It’s a dirty job, but… well, you know the rest.

• Is there a way to use ffmpeg audio filters to automatically synchronize 2 streams with similar content

  29 mai 2015, par user3741412

  I have a situation where I have a video capture of HD content via HDMI with audio from a sound board that goes through a impedance drop into a microphone input of a camcorder. That same signal is split at line level to a ’line in’ jack on the same computer that is capturing the HDMI. Alternatively I can capture the audio via USB from the soundboard which is probably the best plan, but carries with it the same issue.

  The point is that the line in or usb capture will be much higher quality than the one on HDMI because the line out -> impedance change -> mic in path generates inferior quality in that simply brushing the mic jack on the camera while trying to change the zoom (close proximity) can cause noise on the recording.

  So I can do this today :

  • Take the good sound and the camera captured sound and load each into
    audacity and pretty quickly use the timeshift toot to perfectly fit
    the good audio to the questionable audio from the HDMI capture and
    cut the good audio to the exact size of the video. Then I can use
    ffmpeg or other video editing software to replace the questionable
    audio with the better audio.

  But while somewhat quick and easy, it always carries with it a bit of human error and time. I’d like to automate this if possible as this process is repeated at least weekly throughout the year.

  Does anyone have a suggestion if any of these ideas have merit or could suggest another approach ?

  1. I suspect but have yet to confirm that the system timestamp of the start time may be recorded in both audio captured with something like Audacity, or the USB capture tool from the sound board as well as the HDMI mpeg-2 video. I tried ffprobe on a couple audacity captured .wav files but didn’t see anything in the results about such a time code, but perhaps other audio formats or other probing tools may include this info. Can anyone advise if this is common with any particular capture tools or file formats ?

     • if so, I think I could get best results by extracting this information and then using simple adelay and atrim filters in ffmpeg to sync reliably directly from the two sources in one ffmpeg call. This is all theoretical for me right now— I’ve never tried either of these filters yet— just trying to optimize against blind alleys by asking for advice up front.

  2. If such timestamps are not embedded, possibly I can use the file system timestamp for the same idea expressed in 1a, but I suspect the file open of the two capture tools may have different inherant delays. Possibly these delays will be found to be nearly constant and the approach can work with a built-in constant anticipation delay but sounds messy and less reliable than idea 1. Still, I’d take it, if it turns out reasonably reliable

  3. Are there any ffmpeg or general digital audio experts out there that know of particular filters that can be employed on the actual data to look for similarities like normalizing the peak amplitudes or normalizing the amplification of the two to some RMS value and then stepping through a short 10 second snippet of audio, moving one time stream .01s left against the other repeatedly and subtracting the two and looking for a minimum ? Sounds like it could take a while, but if it could do this in less than a minute and be reliable, I suspect it could work. But I have only rudimentary knowledge of audio streams and perhaps what I suggest is just not plausible— but since each stream starts with the same source I think there should be a chance. I am just way out of my depth as to how to go down this road, so if someone out there knows such magic or can throw me some names of filters and example calls, I can explore if I can make it work.

  4. any hardware level suggestions to take a line level output down to a mic level input and not have the problems I am seeing using a simple in-line impedance drop module, so that I can simply rely on the audio from the HDMI ?

  Thanks in advance for any pointers or suggestinons !

• Why is ffmpeg faster than this minimal example ?

  23 juillet 2022, par Dave Ceddia

  I'm wanting to read the audio out of a video file as fast as possible, using the libav libraries. It's all working fine, but it seems like it could be faster.

  


  To get a performance baseline, I ran this ffmpeg command and timed it :

  


  time ffmpeg -threads 1 -i file -map 0:a:0 -f null -


  


  On a test file (a 2.5gb 2hr .MOV with pcm_s16be audio) this comes out to about 1.35 seconds on my M1 Macbook Pro.

  


  On the other hand, this minimal C code (based on FFmpeg's "Demuxing and decoding" example) is consistently around 0.3 seconds slower.

  


  #include <libavcodec></libavcodec>avcodec.h>&#xA;#include <libavformat></libavformat>avformat.h>&#xA;&#xA;static int decode_packet(AVCodecContext *dec, const AVPacket *pkt, AVFrame *frame)&#xA;{&#xA;    int ret = 0;&#xA;&#xA;    // submit the packet to the decoder&#xA;    ret = avcodec_send_packet(dec, pkt);&#xA;&#xA;    // get all the available frames from the decoder&#xA;    while (ret >= 0) {&#xA;        ret = avcodec_receive_frame(dec, frame);&#xA;        av_frame_unref(frame);&#xA;    }&#xA;&#xA;    return 0;&#xA;}&#xA;&#xA;int main (int argc, char **argv)&#xA;{&#xA;    int ret = 0;&#xA;    AVFormatContext *fmt_ctx = NULL;&#xA;    AVCodecContext  *dec_ctx = NULL;&#xA;    AVFrame *frame = NULL;&#xA;    AVPacket *pkt = NULL;&#xA;&#xA;    if (argc != 3) {&#xA;        exit(1);&#xA;    }&#xA;&#xA;    int stream_idx = atoi(argv[2]);&#xA;&#xA;    /* open input file, and allocate format context */&#xA;    avformat_open_input(&amp;fmt_ctx, argv[1], NULL, NULL);&#xA;&#xA;    /* get the stream */&#xA;    AVStream *st = fmt_ctx->streams[stream_idx];&#xA;&#xA;    /* find a decoder for the stream */&#xA;    AVCodec *dec = avcodec_find_decoder(st->codecpar->codec_id);&#xA;&#xA;    /* allocate a codec context for the decoder */&#xA;    dec_ctx = avcodec_alloc_context3(dec);&#xA;&#xA;    /* copy codec parameters from input stream to output codec context */&#xA;    avcodec_parameters_to_context(dec_ctx, st->codecpar);&#xA;&#xA;    /* init the decoder */&#xA;    avcodec_open2(dec_ctx, dec, NULL);&#xA;&#xA;    /* allocate frame and packet structs */&#xA;    frame = av_frame_alloc();&#xA;    pkt = av_packet_alloc();&#xA;&#xA;    /* read frames from the specified stream */&#xA;    while (av_read_frame(fmt_ctx, pkt) >= 0) {&#xA;        if (pkt->stream_index == stream_idx)&#xA;            ret = decode_packet(dec_ctx, pkt, frame);&#xA;&#xA;        av_packet_unref(pkt);&#xA;        if (ret &lt; 0)&#xA;            break;&#xA;    }&#xA;&#xA;    /* flush the decoders */&#xA;    decode_packet(dec_ctx, NULL, frame);&#xA;&#xA;    return ret &lt; 0;&#xA;}&#xA;

  


  I tried measuring parts of this program to see if it was spending a lot of time in the setup, but it's not – at least 1.5 seconds of the runtime is the loop where it's reading frames.

  


  So I took some flamegraph recordings (using cargo-flamegraph) and ran each a few times to make sure the timing was consistent. There's probably some overhead since both were consistently higher than running normally, but they still have the 0.3 second delta.

  


  # 1.812 total
time sudo flamegraph ./minimal file 1

# 1.542 total
time sudo flamegraph ffmpeg -threads 1 -i file -map 0:a:0 -f null - 2>&1


  


  Here are the flamegraphs stacked up, scaled so that the faster one is only 85% as wide as the slower one. (click for larger)

  


  

  


  The interesting thing that stands out to me is how long is spent on read in the minimal example vs. ffmpeg :

  


  

  


  The time spent on lseek is also a lot longer in the minimal program – it's plainly visible in that flamegraph, but in the ffmpeg flamegraph, lseek is a single pixel wide.

  


  What's causing this discrepancy ? Is ffmpeg actually doing less work than I think it is here ? Is the minimal code doing something naive ? Is there some buffering or other I/O optimizations that ffmpeg has enabled ?

  


  How can I shave 0.3 seconds off of the minimal example's runtime ?