零基础读懂视频播放器控制原理: ffplay 播放器源代码分析

视频播放器原理其实大抵相同,都是对音视频帧序列的控制。只是一些播放器在音视频同步上可能做了更为复杂的帧预测技术,来保证音频和视频有更好的同步性。

ffplay 是 FFMpeg 自带的播放器,使用了 ffmpeg 解码库和用于视频渲染显示的 sdl 库,也是业界播放器最初参考的设计标准。本文对 ffplay 源码进行分析,试图用更基础而系统的方法,来尝试解开播放器的音视频同步,以及播放/暂停、快进/后退的控制原理。

由于 FFMpeg 本身的跨平台特性,相比在移动端看音视频代码,在 PC 端利用 VS 查看和调试代码,分析播放器原理,要高效迅速很多。

由于 FFMpeg 官方提供的 ffmplay 在 console 中进行使用不够直观,本文直接分析 CSDN 上将 ffplay 移植到 VC 的代码(ffplay for MFC)进行分析。

文章目录:

一、初探mp4文件

二、以最简单播放器开始:FFmpeg解码 + SDL显示

三、先抛五个问题

四、ffplay代码总体结构

五、视频播放器的操作控制

5.1 ffplay所定义的关键结构体VideoState 5.2 补充基础知识——PTS和DTS 5.2 如何控制音视频同步 5.4 如何控制视频的播放和暂停? 5.5 逐帧播放是如何做的? 5.6 快进和后退

六、 这次分析ffplay代码的反省总结

一、初探mp4文件

为了让大家对视频文件有一个初步认识,首先来看对一个MP4文件的简单分析,如图1。

图1 对MP4文件解参

从图一我们知道,每个视频文件都会有特定的封装格式、比特率、时长等信息。视频解复用之后,就划分为video_stream和audio_stream,分别对应视频流和音频流。

解复用之后的音视频有自己独立的参数,视频参数包括编码方式、采样率、画面大小等,音频参数包括采样率、编码方式和声道数等。

对解复用之后的音频和视频Packet进行解码之后,就变成原始的音频(PWM)和视频(YUV/RGB)数据,才可以在进行显示和播放。

其实这已经差不多涉及到了,视频解码播放的大部分流程,整个视频播放的流程如图2所示。

图2 视频播放流程(图摘自http://blog.csdn.net/leixiaohua1020/article/details/50534150)

二、以最简单播放器开始:FFmpeg解码 + SDL显示

为将问题简单化,先不考虑播放音频,只播放视频,代码流程图如图3所示:

图3 播放器流程图(图源见水印)

流程图说明如下:

1.FFmpeg初始化的代码比较固定,主要目的就是为了设置 AVFormatContext 实例中相关成员变量的值,调用av_register_all、avformat_open_input av_find_stream_info和avcodec_find_decoder等函数。

如图4所示,初始化之后的AVFormatContext实例里面具体的值,调用av_find_stream_info就是找到文件中的音视频流数据,对其中的streams(包含音频、视频流)变量进行初始化。

图4 AVFormatContext初始化实例

2.av_read_frame不断读取stream中的下一帧,对其进行解复用得到视频的AVPacket,随后调用avcodec_decode_video2是视频帧AVPacket进行解码,得到图像帧AVFrame。

3.得到AVFrame之后,接下来就是放到SDL中进行渲染显示了,也很简单,流程见下面代码注释:

SDL_Overlay *bmp;
//将解析得到的AVFrame的数据拷贝到SDL_Overlay实例当中
SDL_LockYUVOverlay(bmp);
bmp->pixels[0]=pFrameYUV->data[0];
bmp->pixels[2]=pFrameYUV->data[1];
bmp->pixels[1]=pFrameYUV->data[2];    
bmp->pitches[0]=pFrameYUV->linesize[0];
bmp->pitches[2]=pFrameYUV->linesize[1];  
bmp->pitches[1]=pFrameYUV->linesize[2];

SDL_UnlockYUVOverlay(bmp);
//设置SDL_Rect,因为涉及到起始点和显示大小,用rect进行表示。
SDL_Rect rect;
rect.x = 0;   
rect.y = 0;   
rect.w = pCodecCtx->width; 
rect.h = pCodecCtx->height;   
//将SDL_Overlay数据显示到SDL_Surface当中。
SDL_DisplayYUVOverlay(bmp, &rect);
//延时40ms,留足ffmpeg取到下一帧并解码该帧的时间,随后继续读取下一帧
SDL_Delay(40);

由上面的原理可知,从帧流中获取到AVPacket,并且解码得到AVFrame,渲染到SDL窗口中。

图5 视频播放状态图

对视频播放的流程总结一下就是:读取下一帧——>解码——>播放——>不断往复,状态图如图5所示。

三、先抛五个问题

本文还是以问题抛问题的思路,以逐步对每个问题进行原理性分析,加深对音视频解码和播放的认识。以下这些问题也是每一个播放器所需要面对的基础问题和原理:

1.我们在观看电影时发现,电影可以更换不同字幕,甚至不同音频,比如中英文字幕和配音,最后在同一个画面中进行显示,视频关于画面、字幕和声音是如何组合的? 其实每一个视频文件,读取出来之后发现,都会被区分不同的流。为了让大家有更具体的理解,以FFMpeg中的代码为例,AVMediaType定义了具体的流类型:

enum AVMediaType {

    AVMEDIA_TYPE_VIDEO,  //视频流

    AVMEDIA_TYPE_AUDIO, //音频流

    AVMEDIA_TYPE_SUBTITLE, //字幕流

};

利用av_read_frame读取出音视频帧之后,随后就利用avcodec_decode_video2对视频捷星解码,或者调用avcodec_decode_audio4对音频进行解码,得到可以供渲染和显示的音视频原始数据。

图像和字幕都将会以Surface或者texture的形式,就像Android中的SurfaceFlinger,将画面不同模块的显示进行组合,生成一幅新的图像,显示在视频画面中。

2.既然视频有帧率的概念,音频有采样率的概念,是否直接利用帧率就可以控制音视频的同步了呢? 每一个视频帧和音频帧在时域上都对应于一个时间点,按道理来说只要控制每一个音视频帧的播放时间,就可以实现同步。

但实际上,对每一帧显示的时间上的精确控制是很难的,更何况音频和视频的解码所需时间不同,极容易引起音视频在时间上的不同步。

所以,播放器具体是如何做音视频同步的呢?

3.视频的音频流、视频流和字幕流,他们在时间上是连续的还是离散的?不同流的帧数相同吗?

由于计算机只能数字模拟离散的世界,所以在时间上肯定是离散的。那既然是离散的,他们的帧数是否相同呢?

视频可以理解为诸多音频帧、视频帧和字幕帧在时间上的序列,他们在时间上的时长,跟视频总时长是相同的,但是由于每个帧解码时间不同,必然会导致他们在每帧的时间间隔不相同。

音频原始数据本身就是采样数据,所以是有固定时钟周期。但是视频假如想跟音频进行同步的话,可能会出现跳帧的情况,每个视频帧播放时间差,都会起伏不定,不是恒定周期。

所以结论是,三者在视频总时长上播放的帧数肯定是不一样的。

4.视频播放就是一系列的连续帧不停渲染。对视频的控制操作包括:暂停和播放、快进和后退。那有没有想过,每次快进/后退的幅度,以时间为量度好,还是以每次跳跃的帧数,就是每次快进是前进多长时间,还是前进多少帧。 时间 VS 帧数?

由上面问题分析,我们知道,视频是以音频流、视频流和字幕流进行分流的,假如以帧数为基础,由于不同流的帧数量不一定相同,以帧数为单位,很容易导致三个流播放的不一致。

因此以时间为量度,相对更好,直接搜寻mp4文件流,当前播放时间的前进或后退时长的seek时间点,随后重新对文件流进行分流解析,就可以达到快进和后退之后的音视频同步效果。

我们可以看到绝大部分播放器,快进/倒退都是以时长为步进的,我们可以看看ffplay是怎么样的,以及是如何实现的。

5.上一节中,实现的简单播放器,解码和播放都是在同一个线程中,解码速度直接影响播放速度,从而将直接造成播放不流畅的问题。那如何在解码可能出现速度不均匀的情况下,进行流畅的视频播放呢?

很容易想到,引入缓冲队列,将视频图像渲染显示和视频解码作为两个线程,视频解码线程往队列中写数据,视频渲染线程从队列中读取数据进行显示,这样就可以保证视频是可以流程播放的。

因此需要采用音频帧、视频帧和字幕帧的三个缓冲队列,那如何保证音视频播放的同步呢?

PTS是视频帧或者音频帧的显示时间戳,究竟是如何利用起来的,从而控制视频帧、音频帧以及字幕帧的显示时刻呢?

那我们就可以探寻ffplay,究竟是如何去做缓冲队列控制的。

所有以上五个问题,我们都将在对ffplay源代码的探寻中,逐步找到更具体的解答。

四、ffplay代码总体结构

图6 ffplay代码总体流程

网上有人做了ffplay的总体流程图,如图6。有了这幅图,代码看起来,就会轻松了很多。流程中具体包含的细节如下:

1.启动定时器Timer,计时器40ms刷新一次,利用SDL事件机制,触发从图像帧队列中读取数据,进行渲染显示;

2.stream_componet_open函数中,av_read_frame()读取到AVPacket,随后放入到音频、视频或字幕Packet队列中;

3.video_thread,从视频packet队列中获取AVPacket并进行解码,得到AVFrame图像帧,放到VideoPicture队列中。

4..audio_thread线程,同video_thread,对音频Packet进行解码;

5.subtitle_thread线程,同video_thread,对字幕Packet进行解码。

五、视频播放器的操作控制

视频播放器的操作包括播放/暂停、快进/倒退、逐帧播放等,这些操作的实现原理是什么呢,下面对其从代码层面逐个进行分析。

5.1 ffplay所定义的关键结构体VideoState

与FFmpeg解码类似,定义了一个AVFormatContext结构体,用于存储文件名、音视频流、解码器等字段,供全局进行访问。

ffplay也定义了一个结构体VideoState,通过对VideoState的分析,就可以大体知道播放器基本实现原理。

typedef struct VideoState {
       // Demux解复用线程,读视频文件stream线程,得到AVPacket,并对packet入栈
       SDL_Thread *read_tid;  
       //视频解码线程,读取AVPacket,decode 爬出可以成AVFrame并入队
       SDL_Thread *video_tid;
       //视频播放刷新线程,定时播放下一帧
       SDL_Thread *refresh_tid;
       int paused;  //控制视频暂停或播放标志位
       int seek_req;  //进度控制标志
       int seek_flags;

       AVStream *audio_st;   //音频流
       PacketQueue audioq;  //音频packet队列
       double audio_current_pts;  //当前音频帧显示时间

       AVStream *subtitle_st; //字幕流
       PacketQueue subtitleq;//字幕packet队列 

       AVStream *video_st; //视频流

       PacketQueue videoq;//视频packet队列
       double video_current_pts; ///当前视频帧pts
       double video_current_pts_drift;  

       VideoPicture pictq[VIDEO_PICTURE_QUEUE_SIZE];  //解码后的图像帧队列
}

从VideoState结构体中可以看出:

1.解复用、视频解码和视频刷新播放,分属三个线程中,并行控制;

2.音频流、视频流、字幕流,都有自己的缓冲队列,供不同线程读写,并且有自己的当前帧的PTS;

3.解码后的图像帧单独放在pictq队列当中,SDL利用其进行显示。

其中PTS是什么呢,这在音视频中是一个很重要的概念,直接决定视频帧或音频帧的显示时间,下面具体介绍一下。

5.2 补充基础知识——PTS和DTS

图7 音视频解码分析

图7为输出的音频帧和视频帧序列,每一帧都有PTS和DTS标签,这两个标签究竟是什么意思呢? DTS(Decode Time Stamp)和PTS(Presentation Time Stamp)都是时间戳,前者是解码时间,后者是显示时间,都是为视频帧、音频帧打上的时间标签,以更有效地支持上层应用的同步机制。

也就是说,视频帧或者音频在解码时,会记录其解码时间,视频帧的播放时间依赖于PTS。

对于声音来说 ,这两个时间标签是相同的;但对于某些视频编码格式,由于采用了双向预测技术,DTS会设置一定的超时或延时,保证音视频的同步,会造成DTS和PTS的不一致。

5.3 如何控制音视频同步

我们已经知道,视频帧的播放时间其实依赖pts字段的,音频和视频都有自己单独的pts。但pts究竟是如何生成的呢,假如音视频不同步时,pts是否需要动态调整,以保证音视频的同步?

下面先来分析,如何控制视频帧的显示时间的:

static void video_refresh(void *opaque){ 

  //根据索引获取当前需要显示的VideoPicture
  VideoPicture *vp = &is->pictq[is->pictq_rindex];

  if (is->paused)
      goto display; //只有在paused的情况下,才播放图像

  // 将当前帧的pts减去上一帧的pts,得到中间时间差

  last_duration = vp->pts - is->frame_last_pts;

  //检查差值是否在合理范围内,因为两个连续帧pts的时间差,不应该太大或太小

  if (last_duration > 0 && last_duration < 10.0) {
    /* if duration of the last frame was sane, update last_duration in video state */
    is->frame_last_duration = last_duration;
  }

  //既然要音视频同步,肯定要以视频或音频为参考标准,然后控制延时来保证音视频的同步,
  //这个函数就做这个事情了,下面会有分析,具体是如何做到的。
  delay = compute_target_delay(is->frame_last_duration, is);

  //获取当前时间
  time= av_gettime()/1000000.0;

   //假如当前时间小于frame_timer + delay,也就是这帧改显示的时间超前,还没到,就直接返回
  if (time < is->frame_timer + delay) 
      return;

  //根据音频时钟,只要需要延时,即delay大于0,就需要更新累加到frame_timer当中。
  if (delay > 0)
       /更新frame_timer,frame_time是delay的累加值
       is->frame_timer += delay * FFMAX(1, floor((time-is->frame_timer) / delay));

  SDL_LockMutex(is->pictq_mutex);

  //更新is当中当前帧的pts,比如video_current_pts、video_current_pos 等变量
  update_video_pts(is, vp->pts, vp->pos);

  SDL_UnlockMutex(is->pictq_mutex);

display:
  /* display picture */
  if (!display_disable)
    video_display(is);
}

函数compute_target_delay根据音频的时钟信号,重新计算了延时,从而达到了根据音频来调整视频的显示时间,从而实现音视频同步的效果。

static double compute_target_delay(double delay, VideoState *is)
{
    double sync_threshold, diff;
   //因为音频是采样数据,有固定的采用周期并且依赖于主系统时钟,要调整音频的延时播放较难控制。所以实际场合中视频同步音频相比音频同步视频实现起来更容易。
   if (((is->av_sync_type == AV_SYNC_AUDIO_MASTER && is->audio_st) ||
     is->av_sync_type == AV_SYNC_EXTERNAL_CLOCK)) {

       //获取当前视频帧播放的时间,与系统主时钟时间相减得到差值
       diff = get_video_clock(is) - get_master_clock(is);
       sync_threshold = FFMAX(AV_SYNC_THRESHOLD, delay);

      //假如当前帧的播放时间,也就是pts,滞后于主时钟
      if (fabs(diff) < AV_NOSYNC_THRESHOLD) {
         if (diff <= -sync_threshold)
             delay = 0;
      //假如当前帧的播放时间,也就是pts,超前于主时钟,那就需要加大延时
      else if (diff >= sync_threshold)
        delay = 2 * delay;
      }

   }
   return delay;
}

图8 音视频帧显示序列

所以这里的流程就很简单了,图8简单画了一个音视频帧序列,想表达的意思是,音频帧数量和视频帧数量不一定对等,另外每个音频帧的显示时间在时间上几乎对等,每个视频帧的显示时间,会根据具体情况有延时显示,这个延时就是有上面的compute_target_delay函数计算出来的。

计算延迟后,更新pts的代码如下:

static void update_video_pts(VideoState *is, double pts, int64_t pos) {

    double time = av_gettime() / 1000000.0;
    /* update current video pts */
    is->video_current_pts = pts;
    is->video_current_pts_drift = is->video_current_pts - time;
    is->video_current_pos = pos;
    is->frame_last_pts = pts;
}

整个流程可以概括为:

显示第一帧视频图像;

根据音频信号,计算出第二帧的delay时间,更新该帧的pts;

当pts到达后,显示第二帧视频图像;

重复以上步骤,到最后一帧。

也许在这里仍然会让人很困惑,为什么单单根据主时钟,就可以播放下一帧所需要的延时呢?

其实视频是具备一定长度的播放流,具体可以分为音频流、视频流和字幕流,三者同时在一起播放形成了视频,当然他们总的播放时间是跟视频文件的播放时长是一样的。

由于音频流本身是pwm采样数据,以固定的频率播放,这个频率是跟主时钟相同或是它的分频,从时间的角度来看,每个音频帧是自然均匀流逝。

所以音频的话,直接按照主时钟或其分频走就可以了。

视频,要根据自己的显示时间即pts,跟主时钟当前的时间进行对比,确定是超前还是滞后于系统时钟,从而确定延时,随后进行准确的播放,这样就可以保证音视频的同步了。

那接下来,还有一个问题,计算出延时之后,难道需要sleep一下做延迟显示吗?

其实并不是如此,上面分析我们知道delay会更新到当前需要更新视频帧的pts (video_current_pts),对当前AVFrame进行显示前,先检测其pts时间,假如还没到,就不进行显示了,直接return。直到下一次刷新,重新进行检测(ffplay采用的40ms定时刷新)。

代码如下,未到更新后的pts时间( is->frame_timer + dela),直接return:

if (av_gettime()/1000000.0 < is->frame_timer + delay)  
    return;

那接下来就是分析如何播放视频帧,就很简单了,只是这里多加了一个字幕流的处理:

static void video_image_display(VideoState *is)
{
    VideoPicture *vp;
   SubPicture *sp;
   AVPicture pict;
   SDL_Rect rect;
   int i;
   vp = &is->pictq[is->pictq_rindex];
   if (vp->bmp) {
       //字幕处理
       if (is->subtitle_st) {}                  
   }

   //计算图像的显示区域
   calculate_display_rect(&rect, is->xleft, is->ytop, is->width, is->height, vp);

   //显示图像
   SDL_DisplayYUVOverlay(vp->bmp, &rect);

   //将pic队列的指针向前移动一个位置
   pictq_next_picture(is);

}

VIDEO_PICTURE_QUEUE_SIZE 只设置为4,很快就会用完了。数据满了如何重新更新呢?

一旦检测到超出队列大小限制,就处于等待状态,直到pictq被取出消费,从而避免开启播放器,就把整个文件全部解码完,这样会代码会很吃内存。

static int queue_picture(VideoState *is, AVFrame *src_frame, double pts1, int64_t pos){

/* keep the last already displayed picture in the queue */
while (is->pictq_size >= VIDEO_PICTURE_QUEUE_SIZE - 2 &&
      !is->videoq.abort_request) {

    SDL_CondWait(is->pictq_cond, is->pictq_mutex);
   }
   SDL_UnlockMutex(is->pictq_mutex);
}

5.4 如何控制视频的播放和暂停?

static void stream_toggle_pause(VideoState *is)
{

    if (is->paused) {
       //由于frame_timer记下来视频从开始播放到当前帧播放的时间,所以暂停后,必须要将暂停的时间( is->video_current_pts_drift - is->video_current_pts)一起累加起来,并加上drift时间。

     is->frame_timer += av_gettime() / 1000000.0 + is->video_current_pts_drift - is->video_current_pts;

     if (is->read_pause_return != AVERROR(ENOSYS)) {
     //并更新video_current_pts
        is->video_current_pts = is->video_current_pts_drift + av_gettime() / 1000000.0;

       }
    //drift其实就是当前帧的pts和当前时间的时间差
    is->video_current_pts_drift = is->video_current_pts - av_gettime() / 1000000.0;
    }

    //paused取反,paused标志位也会控制到图像帧的展示,按一次空格键实现暂停,再按一次就实现播放了。
    is->paused = !is->paused;
}

特别说明:paused标志位控制着视频是否播放,当需要继续播放的时候,一定要重新更新当前所需要播放帧的pts时间,因为这里面要加上已经暂停的时间。

5.5 逐帧播放是如何做的?

在视频解码线程中,不断通过stream_toggle_paused,控制对视频的暂停和显示,从而实现逐帧播放:

static void step_to_next_frame(VideoState *is)
{
   //逐帧播放时,一定要先继续播放,然后再设置step变量,控制逐帧播放
   if (is->paused)
      stream_toggle_pause(is);//会不断将paused进行取反
   is->step = 1;
}

其原理就是不断的播放,然后暂停,从而实现逐帧播放:

static int video_thread(void *arg)
{
  if (is->step)
    stream_toggle_pause(is);
      ……………………
  if (is->paused)
    goto display;//显示视频
  }
}

5.6 快进和后退

关于快进/后退,首先抛出两个问题:

1. 快进以时间为维度还是以帧数为维度来对播放进度进行控制呢?

2.一旦进度发生了变化,那么当前帧,以及AVFrame队列是否需要清零,整个对stream的流是否需要重新来进行控制呢?

ffplay中采用以时间为维度的控制方法。对于快进和后退的控制,都是通过设置VideoState的seek_req、seek_pos等变量进行控制。

do_seek: //实际上是计算is->audio_current_pts_drift + av_gettime() / 1000000.0,确定当前需要播放帧的时间值 pos = get_master_clock(cur_stream); pos += incr; //incr为每次快进的步进值,相加即可得到快进后的时间点 stream_seek(cur_stream, (int64_t)(pos AV_TIME_BASE), (int64_t)(incrAV_TIME_BASE), 0); 关于stream_seek的代码如下,其实就是设置VideoState的相关变量,以控制read_tread中的快进或后退的流程:

/* seek in the stream */
static void stream_seek(VideoState *is, int64_t pos, int64_t rel, int seek_by_bytes)
{

  if (!is->seek_req) {
  is->seek_pos = pos;
  is->seek_rel = rel;
  is->seek_flags &= ~AVSEEK_FLAG_BYTE;
  if (seek_by_bytes)
    is->seek_flags |= AVSEEK_FLAG_BYTE;
  is->seek_req = 1;
}
}

stream_seek中设置了seek_req标志,就直接进入前进/后退控制流程了,其原理是调用avformat_seek_file函数,根据时间戳控制索引点,从而控制需要显示的下一帧:

static int read_thread(void *arg){
//当调整播放进度以后
if (is->seek_req) {
   int64_t seek_target = is->seek_pos;
   int64_t seek_min    = is->seek_rel > 0 ? seek_target - is->seek_rel + 2: INT64_MIN;
   int64_t seek_max    = is->seek_rel < 0 ? seek_target - is->seek_rel - 2: INT64_MAX;
  //根据时间抽查找索引点位置,定位到索引点之后,下一帧的读取直接从这里开始,就实现了快进/后退操作
  ret = avformat_seek_file(is->ic, -1, seek_min, seek_target, seek_max, is->seek_flags);
  if (ret < 0) {
     fprintf(stderr, "s: error while seeking\n", is->ic->filename);
  } else {
  //查找成功之后,就需要清空当前的PAcket队列,包括音频、视频和字幕
     if (is->audio_stream >= 0) {
        packet_queue_flush(&is->audioq);
        packet_queue_put(&is->audioq, &flush_pkt);
     }
     if (is->subtitle_stream >= 0) {//处理字幕stream
        packet_queue_flush(&is->subtitleq);
        packet_queue_put(&is->subtitleq, &flush_pkt);
    }
    if (is->video_stream >= 0) {
       packet_queue_flush(&is->videoq);
       packet_queue_put(&is->videoq, &flush_pkt);
    }
  }
  is->seek_req = 0;
  eof = 0;
  }
}

另外从上面代码中发现,每次快进后退之后都会对audioq、videoq和subtitleq进行flush清零,也是相当于重新开始,保证缓冲队列中的数据的正确性。

对于音频,开始仍然有些困惑,因为在暂停的时候,没有看到对音频的控制,是如何控制的呢?

后来发现,其实暂停的时候设置了is->paused变量,解复用和音频解码和播放都依赖于is->paused变量,所以音频和视频播放都随之停止了。

六、 这次分析ffplay代码的反省总结:

1.基础概念和原理积累,最开始接触FFmpeg,因为其涉及的概念很多,看起来有种无从下手的感觉。这时候必须从基本模块入手,逐步理解更多,一定的量积累,就会产生一些质变,更好的理解视频编解码机制;

2.一定要首先看懂代码总体架构和流程,随后针对每个细节点进行深入分析,会极大提高看代码效率。会画一些框图是非常重要的,比如下面这张,所以简要的流程图要比注重细节的uml图要方便得多;

3.看FFmpeg代码,在PC端上调试,会快捷很多。假如要在Android上,调用jni来看代码,效率就会很低。

参考文章: 基于ffmpeg的跨平台播放器实现 雷神的文章(多媒体入门开发必看)

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CreateAMind

开源|MultiNet模型解决Kitti数据集自动驾驶中的道路分割、车辆检测和街道分类(附源代码)

MultiNet能够同时完成道路分割、汽车检测和道路分类的任务。MultiNet模型的实时存档速度和分割性能都处于最先进水平。详细的模型描述请查阅我们的论文。

1173
来自专栏linux驱动个人学习

GPU与CPU的区别

1263
来自专栏人工智能头条

你们都用 Python 做人脸识别,我就偏要用 Go!

做人脸识别用 Python 比较多,但是今天碰上一个另类,他就跟别人不一样,就不用 Python 用 Go。其实不管是 P 还是 G,能认出脸来就是好样的。

822
来自专栏腾讯移动品质中心TMQ的专栏

当我们讨论流畅度的时候,我们究竟在说什么?

前言:那些年我们用过的显示性能指标 相对其他 Android 性能指标(如内存、CPU、功耗等)而言,显示性能(包括但不仅限于我们常说的“流畅度”)的概念本来...

3989
来自专栏ATYUN订阅号

OpenAI-人工反馈的深度学习

rl-teacher是“Deep Reinforcement Learning from Human Preferences”的实现。 这个系统允许你教一个强化...

3596
来自专栏生信宝典

psRobot:植物小RNA分析系统

psRobot:植物小RNA分析系统 ? 简介 官网:http://omicslab.genetics.ac.cn/psRobot/ PsRobot是中科院遗传...

2056
来自专栏IT技术精选文摘

搜索引擎架构概述

架构 对软件系统来讲,从一个层面对系统的各个组件进行抽象.描述它们各自的功能、提供的接口以及它们之间的关系. 需求 架构为应付需求而产生,对搜索引擎来讲,它主要...

21510
来自专栏AI科技评论

开发 | 深度学习训练时 GPU 温度过高?输入这几行命令就能迅速降温

AI科技评论按:本文作者胡智豪,原载于作者个人博客,AI科技评论经授权发布。 新买回来的不带水冷公版GPU,在满负载运行的时候,温度从室温马上飙升到85度,而且...

35012
来自专栏AI研习社

深度学习训练时 GPU 温度过高?几行命令就可迅速降温!

新买回来的不带水冷公版GPU,在满负载运行的时候,温度从室温马上飙升到85度,而且模型训练不是几分钟完事,很有可能要长期保持在高温状态下运行,让如此昂贵的GPU...

3304
来自专栏Java与Android技术栈

一次简单的验证码识别以及思考

验证码通常用于网站的登录,以区分是否是人类的行为还是机器的行为。启用验证码是反爬虫、反黑客的常用手段之一。然而,随着技术的不断进步,特别是machine lea...

682

扫码关注云+社区