Recherche avancée

Sur d’autres sites (12448)

• Adding AY Files To The Game Music Website

  1er décembre 2013, par Multimedia Mike — General

  For the first time since I launched the site in the summer of last year, I finally added support for new systems for my Game Music Appreciation site : A set of chiptune music files which bear the file extension AY. These files come from games that were on the ZX Spectrum and Amstrad CPC computer systems.

  
   
  

  Right now, there are over 650 ZX Spectrum games in the site while there are all of 20 Amstrad CPC games. The latter system seems a bit short-changed, but I read that a lot of Amstrad games were straight ports from the Spectrum anyway since the systems possessed assorted similarities. This might help explain the discrepancy.

  Technically
  The AY corpus has always been low hanging fruit due to the fact that the site already supports the format courtesy of the game-music-emu backend. The thing that blocked me was that I didn’t know much about these systems. I knew that there were 2 systems (and possibly more) that shared the same chiptune format. Apparently, these machines were big in Europe (I was only vaguely aware of them before I started this project).

  Both the Spectrum and the Amstrad used Zilog Z-80 CPUs for computing and created music using a General Instruments synthesizer chip designated AY-3-8912, hence the chiptune file extension AY. This has 3 channels similar to the C64 SID chip. Additionally, there’s a fourth channel that game music emu calls “beeper” (and which Wikipedia describes as “one channel with 10 octaves”). Per my listening, it seems similar to the old PC speaker/honker. The metadata for a lot of the songs will specify either (AY) or (Beeper).

  Wrangling Metadata
  Large collections of AY files are easy to find ; as is typical for pure chiptunes, the files are incredibly small.

  As usual, the hardest part of the whole process was munging metadata. There seems to be 2 slightly different conventions for AY metadata, likely from 2 different people doing the bulk of the work and releasing the fruits of their labor into the wild. After I recognized the subtle differences between the 2 formats, it was straightforward to craft a tool to perform most of the work, leaving only a minimum of cleanup effort required afterwards.

  (As an aside, I think this process is called extract – transform – load, or ETL. Sounds fancy and complicated, yet it’s technically one of the first computer programming tasks I was ever paid to perform.)

  Collateral Damage
  While pushing this feature, I managed to break the site’s search engine. The search solution I developed was always sketchy (involving compiling a C program as a static binary CGI script and trusting it to run on the server). I will probably need to find a better approach, preferably sooner than later.

• FFmpeg : Encoder did not produce proper pts, making some up

  22 novembre 2022, par Chroluma

  I'm trying to convert a yuv image to jpg format via FFmpeg. But I occured [image2 @ 0x38750] Encoder did not produce proper pts, making some up. while the program was encoding. I looked up some references that someone said avcodec_send_frame can only be used when the frames is more than one. Can I use this way to achieve image conversion ? Here is my code :

  


  int ff_yuv422P_to_jpeg(int imgWidth, int imgHeight, uint8_t* yuvData, int yuvLength)
{
    /* ===== define ===== */
    const char* OutputFileName = "img.jpg";
    int retval = 0;

    /* ===== context ===== */
    struct AVFormatContext* pFormatCtx = avformat_alloc_context();
    avformat_alloc_output_context2(&pFormatCtx, NULL, NULL, OutputFileName);
    struct AVOutputFormat* fmt = pFormatCtx->oformat;

    struct AVStream* video_st = avformat_new_stream(pFormatCtx, 0);
    if (!video_st)
    {
        retval = 1;
        perror("ff_yuv422_to_jpeg(): avformat_new_stream");
        goto out_close_ctx;
    }

    /* ===== codec ===== */
    struct AVCodecContext* pCodecCtx = avcodec_alloc_context3(NULL);
    if (avcodec_parameters_to_context(pCodecCtx, video_st->codecpar) < 0)
    {
        retval = 2;
        perror("ff_yuv422_to_jpeg(): avcodec_parameters_to_context");
        goto out_close_ctx;
    }

    pCodecCtx->codec_id = fmt->video_codec;
    pCodecCtx->codec_type = AVMEDIA_TYPE_VIDEO;
    pCodecCtx->pix_fmt = AV_PIX_FMT_YUVJ422P;
    pCodecCtx->width = imgWidth;
    pCodecCtx->height = imgHeight;
    pCodecCtx->time_base.num = 1;
    pCodecCtx->time_base.den = 25;

    //dump info
    av_dump_format(pFormatCtx, 0, OutputFileName, 1);

    struct AVCodec *pCodec = avcodec_find_encoder(pCodecCtx->codec_id);
    if (!pCodec)
    {
        retval = 3;
        perror("ff_yuv422_to_jpeg(): avcodec_find_encoder");
        goto out_close_st;
    }

    if (avcodec_open2(pCodecCtx, pCodec, NULL) < 0)
    {
        retval = 4;
        perror("ff_yuv422_to_jpeg(): avcodec_open2");
        goto out_close_st;
    }

    /* ===== frame ===== */
    struct AVFrame* pictureFrame = av_frame_alloc();
    pictureFrame->width = pCodecCtx->width;
    pictureFrame->height = pCodecCtx->height;
    pictureFrame->format = AV_PIX_FMT_YUVJ422P;

    int picSize = av_image_get_buffer_size(AV_PIX_FMT_YUVJ422P, pCodecCtx->width, pCodecCtx->height, 1);
    uint8_t* pictureBuffer = (uint8_t*)av_malloc(picSize);
    av_image_fill_arrays(pictureFrame->data, pictureFrame->linesize, pictureBuffer, AV_PIX_FMT_YUVJ422P, pCodecCtx->width, pCodecCtx->height, 1);

    /* ===== write header ===== */
    int notUseRetVal = avformat_write_header(pFormatCtx, NULL);
    
    struct AVPacket* pkt = av_packet_alloc();
    av_new_packet(pkt, imgHeight * imgWidth * 3);
    pictureFrame->data[0] = pictureBuffer + 0 * (yuvLength / 4);
    pictureFrame->data[1] = pictureBuffer + 2 * (yuvLength / 4);
    pictureFrame->data[2] = pictureBuffer + 3 * (yuvLength / 4);

    /* ===== encode ===== */
    int ret = avcodec_send_frame(pCodecCtx, pictureFrame);
    while (ret >= 0)
    {
        pkt->stream_index = video_st->index;
        ret = avcodec_receive_packet(pCodecCtx, pkt);
        if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
        {
            retval = 5;
            perror("ff_yuv422_to_jpeg(): avcodec_receive_packet");
            goto out_close_picture;
        }
        else if (ret < 0)
        {
            retval = 6;
            perror("ff_yuv422_to_jpeg(): avcodec_receive_packet ret < 0");
            goto out_close_picture;
        }
        av_write_frame(pFormatCtx, pkt);
    }
    av_packet_unref(pkt);

    /* ===== write trailer ===== */
    av_write_trailer(pFormatCtx);

#if Print_Debug_Info
    printf("yuv2jpg Encode Success.\n");
#endif

out_close_picture:
    if (pictureFrame) av_free(pictureFrame);
    if (pictureBuffer) av_free(pictureBuffer);

out_close_st:
    // old school
    // if (video_st) avcodec_close(video_st->codec);

out_close_ctx:
    if (pFormatCtx) avformat_free_context(pFormatCtx);

out_return:
    return retval;
}


  


  and my log :

  


  Output #0, image2, to 'img.jpg':
    Stream #0:0: Unknown: none
[image2 @ 0x38750] Encoder did not produce proper pts, making some up.
ff_yuv422_to_jpeg(): avcodec_receive_packet: Success


  


  I looked up the avcodec_receive_packet()'s reference, and my code return error code AVERROR(EAGAIN).

  


• Is ffmpeg broken for h.264 RTP Output ?

  13 mars 2023, par GroovyDotCom

  I used wireshark to capture the RTP stream sent with :

  


  ffmpeg -f lavfi -i "testsrc=duration=5:size=cif:rate=25" -pix_fmt yuv420p -g 25 -bf 2 -an -c:v libx264 -f rtp rtp://127.0.0.1:1234 > play.sdp

  


  ffmpeg -version
ffmpeg version git-2020-03-15-c467328 Copyright (c) 2000-2020 the FFmpeg developers

  


  As can be seen in bold, RTP timestamps go forward and backward. I expect them to be the same for every packet in the frame and then only go forward by 40ms (+3600 at 90khz clock) as per the H.264/RTP spec.

  


  Also, according to that spec, the last packet in a frame should have its marker-bit set but here almost all the packets have this bit set.

  


  Am I doing something wrong ? Not understanding something ? Or is ffmpeg support for writing H.264 RTP simply broken ?

  


  SSRC=0xA49C3DC9, Seq=3595, Time=3153114809
  
SSRC=0xA49C3DC9, Seq=3596, Time=3153114809
  
SSRC=0xA49C3DC9, Seq=3597, Time=3153114809
  
SSRC=0xA49C3DC9, Seq=3598, Time=3153114809, Mark
  
SSRC=0xA49C3DC9, Seq=3599, Time=3153125609, Mark
  
SSRC=0xA49C3DC9, Seq=3600, Time=3153118409, Mark
  
SSRC=0xA49C3DC9, Seq=3601, Time=3153122009, Mark
  
SSRC=0xA49C3DC9, Seq=3602, Time=3153136409, Mark
  
SSRC=0xA49C3DC9, Seq=3603, Time=3153129209, Mark
  
SSRC=0xA49C3DC9, Seq=3604, Time=3153132809, Mark
  
SSRC=0xA49C3DC9, Seq=3605, Time=3153147209, Mark
  
SSRC=0xA49C3DC9, Seq=3606, Time=3153140009, Mark
  
SSRC=0xA49C3DC9, Seq=3607, Time=3153143609, Mark
  
SSRC=0xA49C3DC9, Seq=3608, Time=3153158009, Mark
  
SSRC=0xA49C3DC9, Seq=3609, Time=3153150809, Mark
  
SSRC=0xA49C3DC9, Seq=3610, Time=3153154409, Mark
  
SSRC=0xA49C3DC9, Seq=3611, Time=3153168809, Mark
  
SSRC=0xA49C3DC9, Seq=3612, Time=3153161609, Mark
  
SSRC=0xA49C3DC9, Seq=3613, Time=3153165209, Mark
  
SSRC=0xA49C3DC9, Seq=3614, Time=3153179609, Mark
  
SSRC=0xA49C3DC9, Seq=3615, Time=3153172409, Mark
  
SSRC=0xA49C3DC9, Seq=3616, Time=3153176009, Mark
  
SSRC=0xA49C3DC9, Seq=3617, Time=3153190409, Mark
  
SSRC=0xA49C3DC9, Seq=3618, Time=3153183209, Mark
  

  


  The RTP specification, defined in RFC 3550, states that "the timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations" (Section 5.1).