0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

OpenHarmony 3.2 Beta多媒體系列:音視頻播放gstreamer

電子發(fā)燒友開(kāi)源社區(qū) ? 來(lái)源:未知 ? 2022-11-25 09:10 ? 次閱讀
1f5e2716-6c5d-11ed-8abf-dac502259ad0.png

巴延興

深圳開(kāi)鴻數(shù)字產(chǎn)業(yè)發(fā)展有限公司

資深OS框架開(kāi)發(fā)工程師

一、 簡(jiǎn)介

多媒體播放框架主要的實(shí)現(xiàn)在PlayerServer服務(wù)中,這個(gè)服務(wù)提供了媒體播放框架所需要的實(shí)現(xiàn)環(huán)境,繼續(xù)跟蹤代碼分析發(fā)現(xiàn),PlayerServer主要通過(guò)gstreamer適配層,對(duì)gstreamer進(jìn)行調(diào)用。gstreamer屬于更加具體的實(shí)現(xiàn),所以本篇文章主要是分析PlayerServer通過(guò)適配層調(diào)用到gstreamer的過(guò)程。

此前,我在《OpenHarmony 3.2 Beta多媒體系列-音視頻播放框架》一文中,主要分析了多媒體播放的框架層代碼,本地接口通過(guò)服務(wù)端的proxy代理類(lèi)進(jìn)行IPC調(diào)用,最終調(diào)用到PlayerServer服務(wù)端。本篇主要分析了多媒體gstreamer的調(diào)用,涉及到從PlayerServer到gstreamer的整體流程。

二、 目錄

  gstreamer
    ├── BUILD.gn
    ├── common
    │   ├── BUILD.gn
    │   ├── playbin_adapter
    │   │   ├── i_playbin_ctrler.h
    │   │   ├── playbin2_ctrler.cpp
    │   │   ├── playbin2_ctrler.h
    │   │   ├── playbin_ctrler_base.cpp
    │   │   ├── playbin_ctrler_base.h
    │   │   ├── playbin_msg_define.h
    │   │   ├── playbin_sink_provider.h
    │   │   ├── playbin_state.cpp
    │   │   ├── playbin_state.h
    │   │   ├── playbin_task_mgr.cpp
    │   │   └── playbin_task_mgr.h
    │   ├── state_machine
    │   │   ├── state_machine.cpp
    │   │   └── state_machine.h
    ├── factory
    │   ├── BUILD.gn
    │   └── engine_factory.cpp
    └── player
        ├── BUILD.gn
        ├── player_codec_ctrl.cpp
        ├── player_codec_ctrl.h
        ├── player_engine_gst_impl.cpp
        ├── player_engine_gst_impl.h
        ├── player_sinkprovider.cpp
        ├── player_sinkprovider.h
        ├── player_track_parse.cpp
        └── player_track_parse.h

目錄主要是多媒體子系統(tǒng)中的engine部分,涉及到了gstreamer的適配層,gstreamer具體的實(shí)現(xiàn)是在third_party/gstreamer目錄中。

三 、Gstreamer介紹


1. 簡(jiǎn)介
Gstreamer是一個(gè)跨平臺(tái)的多媒體框架,應(yīng)用程序可以通過(guò)管道(Pipeline)的方式,將多媒體處理的各個(gè)步驟串聯(lián)起來(lái),達(dá)到預(yù)期的效果。每個(gè)步驟通過(guò)元素(Element)基于GObject對(duì)象系統(tǒng)通過(guò)插件(plugins)的方式實(shí)現(xiàn),方便了各項(xiàng)功能的擴(kuò)展。

1f86b4ce-6c5d-11ed-8abf-dac502259ad0.png

2.Gstreamer幾個(gè)重要的概念
Element

Element是Gstreamer中最重要的對(duì)象類(lèi)型之一。一個(gè)element實(shí)現(xiàn)一個(gè)功能(讀取文件,解碼,輸出等),程序需要?jiǎng)?chuàng)建多個(gè)element,并按順序?qū)⑵浯?lián)起來(lái),構(gòu)成一個(gè)完整的Pipeline。

Pad

Pad是一個(gè)element的輸入/輸出接口,分為src pad(生產(chǎn)數(shù)據(jù))和sink pad(消費(fèi)數(shù)據(jù))兩種。兩個(gè)element必須通過(guò)pad才能連接起來(lái),pad擁有當(dāng)前element能處理數(shù)據(jù)類(lèi)型的能力(capabilities),會(huì)在連接時(shí)通過(guò)比較src pad和sink pad中所支持的能力,來(lái)選擇最恰當(dāng)?shù)臄?shù)據(jù)類(lèi)型用于傳輸,如果element不支持,程序會(huì)直接退出。在element通過(guò)pad連接成功后,數(shù)據(jù)會(huì)從上一個(gè)element的src pad傳到下一個(gè)element的sink pad然后進(jìn)行處理。

Bin和Pipeline

Bin是一個(gè)容器,用于管理多個(gè)element,改變bin的狀態(tài)時(shí),bin會(huì)自動(dòng)去修改所包含的element的狀態(tài),也會(huì)轉(zhuǎn)發(fā)所收到的消息。如果沒(méi)有bin,我們需要依次操作我們所使用的element。通過(guò)bin降低了應(yīng)用的復(fù)雜度。

Pipeline繼承自bin,為程序提供一個(gè)bus用于傳輸消息,并且對(duì)所有子element進(jìn)行同步。當(dāng)將Pipeline的狀態(tài)設(shè)置為PLAYING時(shí),Pipeline會(huì)在一個(gè)/多個(gè)新的線程中通過(guò)element處理數(shù)據(jù)。

四、調(diào)用流程

1fadedbe-6c5d-11ed-8abf-dac502259ad0.jpg1fd356d0-6c5d-11ed-8abf-dac502259ad0.jpg ?

左右滑動(dòng)查看更多

五、源碼分析

1. PrepareAsync分析


首先,在PlayerServer的PrepareAsync中會(huì)調(diào)用OnPrepare(false),具體是在OnPrepare(false)中實(shí)現(xiàn),參數(shù)傳入false,表明調(diào)用的是異步方法。

int32_tPlayerServer::PrepareAsync()
{
    std::lock_guard<std::mutex> lock(mutex_);
    MEDIA_LOGW("KPI-TRACE: PlayerServer PrepareAsync in");


    if (lastOpStatus_ == PLAYER_INITIALIZED || lastOpStatus_ == PLAYER_STOPPED) {
        return OnPrepare(false);
    } else {
        MEDIA_LOGE("Can not Prepare, currentState is %{public}s", GetStatusDescription(lastOpStatus_).c_str());
        return MSERR_INVALID_OPERATION;
    }
}


OnPrepare方法中,先通過(guò)playerEngine_調(diào)用SerVideoSurface的方法,將surface_設(shè)置到PlayerEngineGstImpl中(producerSurface_),接著啟動(dòng)一個(gè)任務(wù),調(diào)用目前狀態(tài)的Prepare()方法。

int32_tPlayerServer::OnPrepare(boolsync)
{
    CHECK_AND_RETURN_RET_LOG(playerEngine_ != nullptr, MSERR_NO_MEMORY, "playerEngine_ is nullptr");
    int32_t ret = MSERR_OK;


#ifdef SUPPORT_VIDEO
    if (surface_ != nullptr) {
        ret = playerEngine_->SetVideoSurface(surface_);
        CHECK_AND_RETURN_RET_LOG(ret == MSERR_OK, MSERR_INVALID_OPERATION, "Engine SetVideoSurface Failed!");
    }
#endif


    lastOpStatus_ = PLAYER_PREPARED;


    auto preparedTask = std::make_sharedint32_t<>>([this]() {
        MediaTrace::TraceBegin("PlayerServer::PrepareAsync", FAKE_POINTER(this));
        auto currState = std::static_pointer_cast(GetCurrState());
        return currState->Prepare();
    });


    ret = taskMgr_.LaunchTask(preparedTask, PlayerServerTaskType::STATE_CHANGE);
    CHECK_AND_RETURN_RET_LOG(ret == MSERR_OK, ret, "Prepare launch task failed");


    if (sync) {
        (void)preparedTask->GetResult(); // wait HandlePrpare
    }
    return MSERR_OK;
}

進(jìn)入Preparing狀態(tài)后,會(huì)觸發(fā)PlayerServer的HandlePrepare()方法被調(diào)用,在這個(gè)方法里會(huì)通過(guò)playerEngine_調(diào)用PrepareAsync方法,這個(gè)方法調(diào)用的是PlayerEngineGstImpl對(duì)應(yīng)的PrepareAsync方法。

int32_tPlayerServer::HandlePrepare()
{
    int32_t ret = playerEngine_->PrepareAsync();
    CHECK_AND_RETURN_RET_LOG(ret == MSERR_OK, MSERR_INVALID_OPERATION, "Server Prepare Failed!");
    if (config_.leftVolume <= 1.0f || config_.rightVolume <= 1.0f) {
        ret = playerEngine_->SetVolume(config_.leftVolume, config_.rightVolume);
        MEDIA_LOGD("Prepared SetVolume leftVolume:%{public}f rightVolume:%{public}f, ret:%{public}d", 
                   config_.leftVolume, config_.rightVolume, ret);
    }
    (void)playerEngine_->SetLooping(config_.looping);


    {
        auto rateTask = std::make_sharedvoid<>>([this]() {
            auto currState = std::static_pointer_cast(GetCurrState());
            (void)currState->SetPlaybackSpeed(config_.speedMode);
        });


        (void)taskMgr_.LaunchTask(rateTask, PlayerServerTaskType::RATE_CHANGE);
    }
    return MSERR_OK;
}

首先初始化playBinCtrler_,后續(xù)的操作都是通過(guò)PlayBinCtrlerBase對(duì)象來(lái)操作的,所以PlayBinCtrlerInit()方法會(huì)創(chuàng)建PlayBinCtrlerBase對(duì)象(playBinCtrler_),創(chuàng)建好以后通過(guò)playBinCtrler_進(jìn)行SetSource和SetXXXListener的設(shè)置。

int32_tPlayerEngineGstImpl::PrepareAsync()
{
    std::unique_lock<std::mutex> lock(mutex_);
    MEDIA_LOGD("Prepare in");


    int32_t ret = PlayBinCtrlerInit();
    CHECK_AND_RETURN_RET_LOG(ret == MSERR_OK, MSERR_INVALID_VAL, "PlayBinCtrlerInit failed");


    CHECK_AND_RETURN_RET_LOG(playBinCtrler_ != nullptr, MSERR_INVALID_VAL, "playBinCtrler_ is nullptr");
    ret = playBinCtrler_->PrepareAsync();
    CHECK_AND_RETURN_RET_LOG(ret == MSERR_OK, ret, "PrepareAsync failed");


    // The duration of some resources without header information cannot be obtained.
    MEDIA_LOGD("Prepared ok out");
    return MSERR_OK;
}

初始化完成以后,接下來(lái)進(jìn)行playBinCtrler_的PrepareAsync的調(diào)用,PlayBinCtrlerBase中的PrepareAsync的方法間接地調(diào)用了PrepareAsyncInternal。

int32_tPlayBinCtrlerBase::PrepareAsync()
{
    MEDIA_LOGD("enter");


    std::unique_lock<std::mutex> lock(mutex_);
    return PrepareAsyncInternal();
}

PrepareAsyncInternal首先判斷當(dāng)前的狀態(tài),如果是preparingState或preparedState,那么就直接返回成功,否則繼續(xù)向下調(diào)用。接下來(lái)會(huì)調(diào)用EnterInitializedState(),這個(gè)方法中會(huì)創(chuàng)建playbin,設(shè)置signal的回調(diào)以及gstreamer參數(shù)的設(shè)置。最后調(diào)用目前狀態(tài)的Prepare方法,此時(shí)的狀態(tài)是InitializedState。

int32_t PlayBinCtrlerBase::PrepareAsyncInternal()
{
    if ((GetCurrState() == preparingState_) || (GetCurrState() == preparedState_)) {
        MEDIA_LOGI("already at preparing state, skip");
        return MSERR_OK;
    }


    CHECK_AND_RETURN_RET_LOG((!uri_.empty() || appsrcWrap_), MSERR_INVALID_OPERATION, "Set uri firsty!");


    int32_t ret = EnterInitializedState();
    CHECK_AND_RETURN_RET(ret == MSERR_OK, ret);


    auto currState = std::static_pointer_cast(GetCurrState());
    ret = currState->Prepare();
    CHECK_AND_RETURN_RET_LOG(ret == MSERR_OK, ret, "PrepareAsyncInternal failed");


    return MSERR_OK;
}

InitializedState的Prepare方法又通過(guò)ctrler_調(diào)回到PlayBinCtrlerBase的ChangeState方法,這個(gè)方法是在PlayBinCtrlerBase的父類(lèi)StateMachine中,它是一個(gè)狀態(tài)機(jī),管理著各種狀態(tài)的切換。

int32_t PlayBinCtrlerBase::Prepare()
{
    ctrler_.ChangeState(ctrler_.preparingState_);
    return MSERR_OK;
}

很多表示狀態(tài)的類(lèi)在PlayBinCtrlerBase中進(jìn)行聲明,這些子類(lèi)的具體實(shí)現(xiàn)功能在playbin_state.cpp中。

private:
    class BaseState;
    class IdleState;
    class InitializedState;
    class PreparingState;
    class PreparedState;
    class PlayingState;
    class PausedState;
    class StoppedState;
    class StoppingState;
    class PlaybackCompletedState;

接下來(lái)看一下?tīng)顟B(tài)機(jī)的ChangeState方法,可以看出切換狀態(tài)的時(shí)候,先調(diào)用切換前狀態(tài)的StateExit()方法,再調(diào)用切換后狀態(tài)的StateEnter()。如果需要一些操作,我們可以在狀態(tài)的StateEnter和StateExit中進(jìn)行。

voidStateMachine::ChangeState(conststd::shared_ptr&state)
{
    ......
    if (currState_ != nullptr && currState_->GetStateName() == "stopping_state" && state->GetStateName() != "stopped_state") {
        return;
    }
    if (currState_) {
        currState_->StateExit();
    }
    currState_ = state;
    state->StateEnter();
}

因?yàn)樯厦媲袚Q狀態(tài)調(diào)用的是ctrler_.ChangeState(ctrler_.preparingState_),所以接下來(lái)看一下PreparingState狀態(tài)的StateEnter方法。這個(gè)方法中首先是調(diào)用了ctrler_.ReportMessage(msg),字面上看是用來(lái)上報(bào)msg信息的。

voidPlayBinCtrlerBase::StateEnter()
{
    PlayBinMessage msg = { PLAYBIN_MSG_SUBTYPE, PLAYBIN_SUB_MSG_BUFFERING_START, 0, {} };
    ctrler_.ReportMessage(msg);


    GstStateChangeReturn ret;
    (void)ChangePlayBinState(GST_STATE_PAUSED, ret);


    MEDIA_LOGD("PreparingState::StateEnter finished");
}

ctrler_是PlayBinCtrlerBase類(lèi)型的變量,直接看PlayBinCtrlerBase的ReportMessage方法,這個(gè)方法的核心,是創(chuàng)建一個(gè)任務(wù)后,將任務(wù)放入消息隊(duì)列中,等待消息被處理,這里我們最想知道的是這個(gè)消息會(huì)在什么地方被處理。msgReportHandler創(chuàng)建了TaskHandler,這個(gè)里面會(huì)調(diào)用notifier_(msg),這里的notifier_比較重要,我們可以順著這個(gè)變量向上分析。

voidPlayBinCtrlerBase::ReportMessage(constPlayBinMessage&msg)
{
    ......
    auto msgReportHandler = std::make_sharedvoid<>>([this, msg]() { notifier_(msg); });
    int32_t ret = msgQueue_->EnqueueTask(msgReportHandler);
    if (ret != MSERR_OK) {
        MEDIA_LOGE("async report msg failed, type: %{public}d, subType: %{public}d, code: %{public}d",
                   msg.type, msg.subType, msg.code);
    };


    if (msg.type == PlayBinMsgType::PLAYBIN_MSG_EOS) {
        ProcessEndOfStream();
    }
}

notifier_是在PlayBinCtrlerBase被創(chuàng)建的時(shí)候賦值的。

PlayBinCtrlerBase::PlayBinCtrlerBase(constPlayBinCreateParam&createParam)
    : renderMode_(createParam.renderMode),
    notifier_(createParam.notifier),
    sinkProvider_(createParam.sinkProvider)
{
    MEDIA_LOGD("enter ctor, instance: 0x%{public}06" PRIXPTR "", FAKE_POINTER(this));
}

在源碼分析的前期PlayerEngineGstImpl初始化PlayBinCtrlerBase的時(shí)候進(jìn)行了創(chuàng)建notifier = std::bind(&PlayerEngineGstImpl::OnNotifyMessage, this, std::_1) notifier相當(dāng)于是調(diào)用了PlayerEngineGstImpl::OnNotifyMessage方法。所以上述中的處理函數(shù)就是PlayerEngineGstImpl::OnNotifyMessage。

int32_tPlayerEngineGstImpl::PlayBinCtrlerPrepare()
{
    uint8_t renderMode = IPlayBinCtrler::DEFAULT_RENDER;
    auto notifier = std::bind(&PlayerEngineGstImpl::OnNotifyMessage, this, std::_1);


    {
        std::unique_lock<std::mutex> lk(trackParseMutex_);
        sinkProvider_ = std::make_shared(producerSurface_);
        sinkProvider_->SetAppInfo(appuid_, apppid_);
    }


    IPlayBinCtrler::PlayBinCreateParam createParam = {
        static_cast(renderMode), notifier, sinkProvider_
    };
    playBinCtrler_ = IPlayBinCtrler::PLAYBIN2, createParam);
    ......
    return MSERR_OK;
}

在OnNotifyMessage中指定了各種消息類(lèi)型對(duì)應(yīng)的執(zhí)行函數(shù),上述代碼中創(chuàng)建的Message類(lèi)型是PLAYBIN_MSG_SUBTYPE,子類(lèi)型為PLAYBIN_SUB_MSG_BUFFERING_START。

voidPlayerEngineGstImpl::OnNotifyMessage(constPlayBinMessage&msg)
{
    const std::unordered_map MSG_NOTIFY_FUNC_TABLE = {,>
        { PLAYBIN_MSG_ERROR, std::bind(&PlayerEngineGstImpl::HandleErrorMessage, this, std::_1) },
        { PLAYBIN_MSG_SEEKDONE, std::bind(&PlayerEngineGstImpl::HandleSeekDoneMessage, this, std::_1) },
        { PLAYBIN_MSG_SPEEDDONE, std::bind(&PlayerEngineGstImpl::HandleInfoMessage, this, std::_1) },
        { PLAYBIN_MSG_BITRATEDONE, std::bind(&PlayerEngineGstImpl::HandleInfoMessage, this, std::_1)},
        { PLAYBIN_MSG_EOS, std::bind(&PlayerEngineGstImpl::HandleInfoMessage, this, std::_1) },
        { PLAYBIN_MSG_STATE_CHANGE, std::bind(&PlayerEngineGstImpl::HandleInfoMessage, this, std::_1) },
        { PLAYBIN_MSG_SUBTYPE, std::bind(&PlayerEngineGstImpl::HandleSubTypeMessage, this, std::_1) },
        { PLAYBIN_MSG_AUDIO_SINK, std::bind(&PlayerEngineGstImpl::HandleAudioMessage, this, std::_1) },
        { PLAYBIN_MSG_POSITION_UPDATE, std::bind(&PlayerEngineGstImpl::HandlePositionUpdateMessage, this,
            std::_1) },
    };
    if (MSG_NOTIFY_FUNC_TABLE.count(msg.type) != 0) {
        MSG_NOTIFY_FUNC_TABLE.at(msg.type)(msg);
    }
}

最終的流程走到了PlayerEngineGstImpl::HandleBufferingStart(),在這個(gè)方法中,主要通過(guò)obs_將format傳給IPlayerEngineObs的OnInfo方法。

voidPlayerEngineGstImpl::HandleBufferingStart()
{
    percent_ = 0;
    Format format;
(void)format.PutIntValue(std::string(PlayerKeys::PLAYER_BUFFERING_START), 0);
    std::shared_ptr notifyObs = obs_.lock();
    if (notifyObs != nullptr) {
        notifyObs->OnInfo(INFO_TYPE_BUFFERING_UPDATE, 0, format);
    }
}

我們重點(diǎn)看一下obs_是哪里設(shè)置的,在PlayerServer的初始化InitPlayEngine。shared_from_this()相當(dāng)于是把PlayerServer自身賦值給obs,PlayerServer也是實(shí)現(xiàn)了IPlayerEngineObs對(duì)應(yīng)的接口。

int32_tPlayerServer::InitPlayEngine(conststd::string&url)
{
    ......
    int32_t ret = taskMgr_.Init();
    auto engineFactory = EngineFactoryRepo::SCENE_PLAYBACK, url);
    
    playerEngine_ = engineFactory->CreatePlayerEngine(appUid_, appPid_);


    if (dataSrc_ == nullptr) {
        ret = playerEngine_->SetSource(url);
    } else {
        ret = playerEngine_->SetSource(dataSrc_);
    }


    std::shared_ptr obs = shared_from_this();
    ret = playerEngine_->SetObs(obs);


    lastOpStatus_ = PLAYER_INITIALIZED;
    ChangeState(initializedState_);


    return MSERR_OK;
}

這樣我們就跟蹤到了PlayerServer的OnInfo()方法。

voidPlayerServer::OnInfo(PlayerOnInfoTypetype,int32_textra,constFormat&infoBody)
{
    std::lock_guard<std::mutex> lockCb(mutexCb_);


    int32_t ret = HandleMessage(type, extra, infoBody);
    if (playerCb_ != nullptr && ret == MSERR_OK) {
        playerCb_->OnInfo(type, extra, infoBody);
    }
}

2. Play分析

從PlayerServer開(kāi)始跟蹤,調(diào)用到PlayerServer的OnPlay()方法。

int32_tPlayerServer::Play()
{
    ......
    if (lastOpStatus_ == PLAYER_PREPARED || lastOpStatus_ == PLAYER_PLAYBACK_COMPLETE ||
        lastOpStatus_ == PLAYER_PAUSED) {
        return OnPlay();
    } else {
        return MSERR_INVALID_OPERATION;
    }
}

在OnPlay中會(huì)啟動(dòng)一個(gè)任務(wù),在任務(wù)中獲取當(dāng)前的狀態(tài),然后調(diào)用當(dāng)前狀態(tài)的Play()方法。

int32_tPlayerServer::OnPlay()
{
    ......
    auto playingTask = std::make_sharedvoid<>>([this]() {
        auto currState = std::static_pointer_cast(GetCurrState());
        (void)currState->Play();
    });


    int ret = taskMgr_.LaunchTask(playingTask, PlayerServerTaskType::STATE_CHANGE);


    lastOpStatus_ = PLAYER_STARTED;
    return MSERR_OK;
}

前面調(diào)用了PrepareAsync,所以當(dāng)前的狀態(tài)是Prepared,調(diào)用到了PreparedState的Play()方法,這個(gè)方法還是按照之前Prepare的方式,調(diào)回到PlayerServer的HandlePlay()。

int32_tPlayerServer::Play()
{
    return server_.HandlePlay();
}

在PlayServer中通過(guò)播放引擎繼續(xù)向下調(diào)用。

int32_tPlayerServer::HandlePlay()
{
    int32_t ret = playerEngine_->Play();
    CHECK_AND_RETURN_RET_LOG(ret == MSERR_OK, MSERR_INVALID_OPERATION, "Engine Play Failed!");


    return MSERR_OK;
}

在PlayerEngineGstImpl的Play()方法會(huì)繼續(xù)調(diào)用playBinCtrler_的Play()方法。

int32_tPlayerEngineGstImpl::Play()
{
    ......
    playBinCtrler_->Play();
    return MSERR_OK;
}

PlayBinCtrlerBase的Play()方法根據(jù)當(dāng)前的State,調(diào)用currSate->Play()。

int32_tPlayBinCtrlerBase::Play()
{
    ......
    auto currState =    std::static_pointer_cast(GetCurrState());
    int32_t ret = currState->Play();


    return MSERR_OK;
}

在PreparedState的Play()方法中改變了PlayBin的狀態(tài)為playing。

int32_tPlayBinCtrlerBase::Play()
{
    GstStateChangeReturn ret;
    return ChangePlayBinState(GST_STATE_PLAYING, ret);
}

ChangePlayBinState主要是調(diào)用了gst_element_set_state(GST_ELEMENT_CAST(ctrler_.playbin_),GST_STATE_PLAYING),這個(gè)直接調(diào)用了gstreamer三方庫(kù)的實(shí)現(xiàn),調(diào)用完這個(gè)方法以后,gstreamer就開(kāi)始進(jìn)行播放了。

int32_tPlayBinCtrlerBase::ChangePlayBinState(GstStatetargetState,GstStateChangeReturn&ret)
{
    ......
    ret = gst_element_set_state(GST_ELEMENT_CAST(ctrler_.playbin_), targetState);
    if (ret == GST_STATE_CHANGE_FAILURE) {
        MEDIA_LOGE("Failed to change playbin's state to %{public}s", gst_element_state_get_name(targetState));
        return MSERR_INVALID_OPERATION;
    }


    return MSERR_OK;
}

六、總結(jié)

本篇文章主要從PlayerServer播放服務(wù)開(kāi)始分析音視頻播放的流程,涉及到gstreamer引擎的調(diào)用,相對(duì)于多媒體播放框架來(lái)說(shuō),更加底層,便于熟悉從框架到gstreamer的整體流程。

更多熱點(diǎn)文章閱讀

  • 玩嗨OpenHarmony:基于OpenHarmony的智能助老服務(wù)機(jī)器人
  • 玩嗨OpenHarmony:基于OpenHarmony的智慧農(nóng)業(yè)環(huán)境監(jiān)控系統(tǒng)
  • 首個(gè)通過(guò)OpenHarmony兼容性測(cè)評(píng)的全場(chǎng)景實(shí)驗(yàn)箱
  • 基于OpenHarmony的智能門(mén)禁系統(tǒng),讓出行更便捷
  • OpenHarmony 3.2 Beta多媒體系列:音視頻播放框架

提示:本文電子發(fā)燒友社區(qū)發(fā)布,轉(zhuǎn)載請(qǐng)注明以上來(lái)源。如需社區(qū)合作及入群交流,請(qǐng)?zhí)砑游⑿臙EFans0806,或者發(fā)郵箱liuyong@huaqiu.com。


原文標(biāo)題:OpenHarmony 3.2 Beta多媒體系列:音視頻播放gstreamer

文章出處:【微信公眾號(hào):電子發(fā)燒友開(kāi)源社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。


聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴

原文標(biāo)題:OpenHarmony 3.2 Beta多媒體系列:音視頻播放gstreamer

文章出處:【微信號(hào):HarmonyOS_Community,微信公眾號(hào):電子發(fā)燒友開(kāi)源社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    dm368錄制音視頻后用vlc播放不同步是怎么回事?

    目前我們用其他的開(kāi)發(fā)板 能夠錄制音視頻,但是用vlc播放的時(shí)候發(fā)現(xiàn)每次都是視頻播放完成了音頻還要播放一會(huì),隨著錄制時(shí)間加上,延后的這個(gè)時(shí)間
    發(fā)表于 10-15 06:56

    盤(pán)點(diǎn)那些常見(jiàn)音視頻接口

    我們熟知的一些常見(jiàn)音視頻接口,發(fā)展至今在日常使用中已經(jīng)漸漸少了。但是在工業(yè)領(lǐng)域的音視頻連接,依然能看到其身影。這些看似消失的接口,它們現(xiàn)在發(fā)展成什么樣子了?本期我們將做一個(gè)大盤(pán)點(diǎn)。
    的頭像 發(fā)表于 09-09 14:34 ?423次閱讀

    常見(jiàn)音視頻接口的靜電浪涌防護(hù)和濾波方案

    音視頻接口在現(xiàn)代多媒體設(shè)備中扮演著至關(guān)重要的角色,它們確保了音視頻信號(hào)在不同設(shè)備間的順暢傳輸,各種類(lèi)型的音視頻接口滿(mǎn)足了多樣化的應(yīng)用場(chǎng)景需求。 在
    的頭像 發(fā)表于 06-25 11:28 ?584次閱讀

    分享一款高清HDMI音視頻采集編碼卡,支持雙碼流

    “靈卡CAS”系列HDMI音視頻采集卡。獨(dú)具匠心的設(shè)計(jì)與功能配置,適用于各種規(guī)模的商務(wù)會(huì)議、多媒體教育以及數(shù)字化展示等各類(lèi)場(chǎng)景。
    的頭像 發(fā)表于 05-07 11:43 ?333次閱讀
    分享一款高清HDMI<b class='flag-5'>音視頻</b>采集編碼卡,支持雙碼流

    【RTC程序設(shè)計(jì):實(shí)時(shí)音視頻權(quán)威指南】音視頻的編解碼壓縮技術(shù)

    音視頻所載有的信息在通過(guò)傳輸?shù)臅r(shí)候就需要壓縮編碼。 其中,文本壓縮是指通過(guò)使用各種算法和技術(shù),將文本數(shù)據(jù)表示為更緊湊的形式,以減少存儲(chǔ)空間。 霍夫曼編碼是一種無(wú)損壓縮算法,它可以根據(jù)字符出現(xiàn)
    發(fā)表于 04-28 21:04

    OpenHarmony4.0源碼解析之媒體框架

    媒體框架簡(jiǎn)介 媒體框架 multimedia_player_framework 主要提供音視頻的錄制與播放功能。 框架簡(jiǎn)介 從框架圖中可以看出,媒體
    的頭像 發(fā)表于 02-26 22:05 ?723次閱讀
    <b class='flag-5'>OpenHarmony</b>4.0源碼解析之<b class='flag-5'>媒體</b>框架

    音視頻解碼生成:打造你的專(zhuān)屬高清影院體驗(yàn)

    在數(shù)字化時(shí)代,人們對(duì)觀影體驗(yàn)的要求越來(lái)越高。音視頻解碼生成技術(shù),作為現(xiàn)代多媒體播放的核心,正是為了滿(mǎn)足這種需求而不斷發(fā)展和完善的。通過(guò)這項(xiàng)技術(shù),我們可以輕松打造屬于自己的高清影院體驗(yàn)。 一、高清畫(huà)質(zhì)
    的頭像 發(fā)表于 02-25 14:47 ?373次閱讀

    音視頻解碼生成:打造極致觀影體驗(yàn)的關(guān)鍵技術(shù)

    在現(xiàn)代多媒體時(shí)代,音視頻解碼生成技術(shù)已成為提供極致觀影體驗(yàn)的核心要素。它不僅能夠確保音視頻數(shù)據(jù)的高效傳輸,還能保證播放的流暢性和畫(huà)質(zhì)清晰度,為用戶(hù)帶來(lái)身臨其境的觀影享受。 1. 解碼生
    的頭像 發(fā)表于 02-25 14:43 ?425次閱讀

    音視頻解碼器優(yōu)化技巧:提升播放體驗(yàn)的關(guān)鍵步驟

    隨著數(shù)字多媒體內(nèi)容的爆炸式增長(zhǎng),音視頻解碼器在現(xiàn)代技術(shù)生活中扮演著至關(guān)重要的角色。從流暢的在線視頻播放到高質(zhì)量的本地文件解碼,解碼器的性能直接影響了我們的觀看體驗(yàn)。那么,如何優(yōu)化
    的頭像 發(fā)表于 02-21 14:45 ?727次閱讀

    音視頻解碼器硬件加速:實(shí)現(xiàn)更流暢的播放效果

    隨著多媒體內(nèi)容的日益豐富和高清化,傳統(tǒng)的軟件解碼已經(jīng)難以滿(mǎn)足人們對(duì)流暢播放體驗(yàn)的需求。因此,音視頻解碼器硬件加速技術(shù)的出現(xiàn),為提升播放效果帶來(lái)了革命性的改變。 硬件加速的原理 硬件加速
    的頭像 發(fā)表于 02-21 14:40 ?888次閱讀
    <b class='flag-5'>音視頻</b>解碼器硬件加速:實(shí)現(xiàn)更流暢的<b class='flag-5'>播放</b>效果

    音視頻解碼生成在多媒體制作中的應(yīng)用

    音視頻解碼生成是多媒體制作中不可或缺的一部分,它扮演著將編碼的音視頻數(shù)據(jù)轉(zhuǎn)化為可播放、可編輯的內(nèi)容的關(guān)鍵角色。在多媒體制作的全過(guò)程中,
    的頭像 發(fā)表于 02-21 14:39 ?344次閱讀

    音視頻解碼生成與流媒體傳輸?shù)慕Y(jié)合

    音視頻解碼生成與流媒體傳輸是現(xiàn)代數(shù)字媒體技術(shù)中兩個(gè)不可或缺的部分,它們的結(jié)合為用戶(hù)提供了高質(zhì)量、實(shí)時(shí)性的多媒體體驗(yàn)。 1. 解碼生成與流媒體
    的頭像 發(fā)表于 02-21 14:36 ?355次閱讀

    萬(wàn)興科技發(fā)布國(guó)內(nèi)首個(gè)音視頻多媒體大模型“天幕”

    萬(wàn)興科技近日正式發(fā)布了國(guó)內(nèi)首個(gè)音視頻多媒體大模型——萬(wàn)興“天幕”,并宣布大模型研發(fā)中心將正式落戶(hù)馬欄山。
    的頭像 發(fā)表于 02-04 11:42 ?1221次閱讀

    音視頻

    對(duì)音視頻技術(shù)都喜歡深究?jī)?nèi)部最核心的原理和機(jī)制,尤其是ffmpeg這個(gè)編解碼庫(kù),可以說(shuō)是音視頻領(lǐng)域事實(shí)上的標(biāo)準(zhǔn)。語(yǔ)音智能算法,語(yǔ)言語(yǔ)義分析和理解,流媒體服務(wù)器等高端技術(shù)也都基于它而構(gòu)建。希望有幸獲得本書(shū),深度學(xué)習(xí)ffmpeg核心技
    發(fā)表于 11-23 08:51

    關(guān)于手機(jī)端音視頻技術(shù)的思考與經(jīng)驗(yàn)

    提起手機(jī)音視頻,大家的第一印象可能是上面列舉的抖音、快手、愛(ài)奇藝和小米視頻等在線視頻平臺(tái),其中我們的小米視頻是一個(gè)聚合平臺(tái),用戶(hù)可以通過(guò)它觀看各大流
    發(fā)表于 11-17 09:43 ?822次閱讀
    關(guān)于手機(jī)端<b class='flag-5'>音視頻</b>技術(shù)的思考與經(jīng)驗(yàn)