Question

Je travaille sur certains logiciels en streaming qui prend des flux en direct de divers types de caméras et de flux sur le réseau en utilisant H.264. Pour ce faire, j'utilise directement le codeur X264 (avec le préréglage "Zerolatence") et nourrir les naux comme ils sont disponibles pour LibavAformat pour emballer dans le RTP (finalement RTSP). Idéalement, cette L'application devrait être aussi en temps réel que possible. Pour la plupart, Cela fonctionne bien.

Malheureusement, cependant, il existe une sorte de problème de synchronisation: Toute lecture vidéo sur les clients semble montrer quelques cadres lisses, suivi d'une courte pause, alors plus de cadres; répéter. Aditionellement, Il semble y avoir un délai d'environ 4 secondes. Cela arrive avec Chaque lecteur vidéo que j'ai essayé: Totem, VLC et des tuyaux de base Gstreamer.

J'ai tout bouilli à un cas de test un peu petit:

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>
#include <x264.h>
#include <libavformat/avformat.h>
#include <libswscale/swscale.h>

#define WIDTH       640
#define HEIGHT      480
#define FPS         30
#define BITRATE     400000
#define RTP_ADDRESS "127.0.0.1"
#define RTP_PORT    49990

struct AVFormatContext* avctx;
struct x264_t* encoder;
struct SwsContext* imgctx;

uint8_t test = 0x80;


void create_sample_picture(x264_picture_t* picture)
{
    // create a frame to store in
    x264_picture_alloc(picture, X264_CSP_I420, WIDTH, HEIGHT);

    // fake image generation
    // disregard how wrong this is; just writing a quick test
    int strides = WIDTH / 8;
    uint8_t* data = malloc(WIDTH * HEIGHT * 3);
    memset(data, test, WIDTH * HEIGHT * 3);
    test = (test << 1) | (test >> (8 - 1));

    // scale the image
    sws_scale(imgctx, (const uint8_t* const*) &data, &strides, 0, HEIGHT,
              picture->img.plane, picture->img.i_stride);
}

int encode_frame(x264_picture_t* picture, x264_nal_t** nals)
{
    // encode a frame
    x264_picture_t pic_out;
    int num_nals;
    int frame_size = x264_encoder_encode(encoder, nals, &num_nals, picture, &pic_out);

    // ignore bad frames
    if (frame_size < 0)
    {
        return frame_size;
    }

    return num_nals;
}

void stream_frame(uint8_t* payload, int size)
{
    // initalize a packet
    AVPacket p;
    av_init_packet(&p);
    p.data = payload;
    p.size = size;
    p.stream_index = 0;
    p.flags = AV_PKT_FLAG_KEY;
    p.pts = AV_NOPTS_VALUE;
    p.dts = AV_NOPTS_VALUE;

    // send it out
    av_interleaved_write_frame(avctx, &p);
}

int main(int argc, char* argv[])
{
    // initalize ffmpeg
    av_register_all();

    // set up image scaler
    // (in-width, in-height, in-format, out-width, out-height, out-format, scaling-method, 0, 0, 0)
    imgctx = sws_getContext(WIDTH, HEIGHT, PIX_FMT_MONOWHITE,
                            WIDTH, HEIGHT, PIX_FMT_YUV420P,
                            SWS_FAST_BILINEAR, NULL, NULL, NULL);

    // set up encoder presets
    x264_param_t param;
    x264_param_default_preset(&param, "ultrafast", "zerolatency");

    param.i_threads = 3;
    param.i_width = WIDTH;
    param.i_height = HEIGHT;
    param.i_fps_num = FPS;
    param.i_fps_den = 1;
    param.i_keyint_max = FPS;
    param.b_intra_refresh = 0;
    param.rc.i_bitrate = BITRATE;
    param.b_repeat_headers = 1; // whether to repeat headers or write just once
    param.b_annexb = 1;         // place start codes (1) or sizes (0)

    // initalize
    x264_param_apply_profile(&param, "high");
    encoder = x264_encoder_open(&param);

    // at this point, x264_encoder_headers can be used, but it has had no effect

    // set up streaming context. a lot of error handling has been ommitted
    // for brevity, but this should be pretty standard.
    avctx = avformat_alloc_context();
    struct AVOutputFormat* fmt = av_guess_format("rtp", NULL, NULL);
    avctx->oformat = fmt;

    snprintf(avctx->filename, sizeof(avctx->filename), "rtp://%s:%d", RTP_ADDRESS, RTP_PORT);
    if (url_fopen(&avctx->pb, avctx->filename, URL_WRONLY) < 0)
    {
        perror("url_fopen failed");
        return 1;
    }
    struct AVStream* stream = av_new_stream(avctx, 1);

    // initalize codec
    AVCodecContext* c = stream->codec;
    c->codec_id = CODEC_ID_H264;
    c->codec_type = AVMEDIA_TYPE_VIDEO;
    c->flags = CODEC_FLAG_GLOBAL_HEADER;
    c->width = WIDTH;
    c->height = HEIGHT;
    c->time_base.den = FPS;
    c->time_base.num = 1;
    c->gop_size = FPS;
    c->bit_rate = BITRATE;
    avctx->flags = AVFMT_FLAG_RTP_HINT;

    // write the header
    av_write_header(avctx);

    // make some frames
    for (int frame = 0; frame < 10000; frame++)
    {
        // create a sample moving frame
        x264_picture_t* pic = (x264_picture_t*) malloc(sizeof(x264_picture_t));
        create_sample_picture(pic);

        // encode the frame
        x264_nal_t* nals;
        int num_nals = encode_frame(pic, &nals);

        if (num_nals < 0)
            printf("invalid frame size: %d\n", num_nals);

        // send out NALs
        for (int i = 0; i < num_nals; i++)
        {
            stream_frame(nals[i].p_payload, nals[i].i_payload);
        }

        // free up resources
        x264_picture_clean(pic);
        free(pic);

        // stream at approx 30 fps
        printf("frame %d\n", frame);
        usleep(33333);
    }

    return 0;
}

Ce test montre des lignes noires sur un fond blanc que devrait se déplacer en douceur vers la gauche. Il a été écrit pour FFMPEG 0.6.5 Mais le problème peut être reproduit sur 0,8 et 0,10 (de ce que j'ai testé jusqu'à présent). J'ai pris des raccourcis dans la gestion des erreurs pour rendre cet exemple aussi court que possible tout en montrant le problème, alors veuillez excuser une partie de la Code Nasty. Je devrais aussi noter que pendant qu'un SDP n'est pas utilisé ici, je ont essayé d'utiliser cela déjà avec des résultats similaires. Le test peut être compilé avec:

gcc -g -std=gnu99 streamtest.c -lswscale -lavformat -lx264 -lm -lpthread -o streamtest

Il peut être joué directement avec GTREAMER:

gst-launch udpsrc port=49990 ! application/x-rtp,payload=96,clock-rate=90000 ! rtph264depay ! decodebin ! xvimagesink

Vous devez immédiatement remarquer le bégaiement. Un "correction" commun que j'ai vu partout sur Internet consiste à ajouter de la synchronisation= false au pipeline:

gst-launch udpsrc port=49990 ! application/x-rtp,payload=96,clock-rate=90000 ! rtph264depay ! decodebin ! xvimagesink sync=false

Cela provoque une lecture en douceur (et à proximité de temps réel), mais est une Non-solution et fonctionne uniquement avec Gstreamer. Je voudrais réparer le problème à la source. J'ai été capable de diffuser avec du presque identique Paramètres utilisant RAW FFMPEG et n'ont eu aucun problème:

ffmpeg -re -i sample.mp4 -vcodec libx264 -vpre ultrafast -vpre baseline -b 400000 -an -f rtp rtp://127.0.0.1:49990 -an

Si clairement je fais quelque chose de mal. Mais qu'est-ce que c'est?

Était-ce utile?

La solution

1) Vous n'avez pas réglé PTS pour les cadres que vous envoyez à libx264 (vous devriez probablement voir des avertissements «non strictement monotoniques») 2) Vous n'avez pas réglé PTS / DTS pour des paquets que vous envoyez au Muxer RTP de LibavFormat (je ne suis pas sûr de 100%, mais je suppose que ce serait mieux. Du code source, il ressemble à des PTS RTP). 3) IMHO USLEEP (33333) est mauvais.Il provoque également le décodeur de l'encodeur (augmentation de la latence) pendant que vous pouviez coder la trame suivante pendant cette période, même si vous n'avez toujours pas besoin de l'envoyer par RTP.

P.s.BTW Vous n'avez pas défini param .rc.i_rc_method sur x264_rc_abr SO LibX264 utilisera plutôt CRF 23 et ignorera votre "param.rc.i_bittrate= bitTre".En outre, il peut être une bonne idée d'utiliser VBV lors de l'encodage pour l'envoi de réseau.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top