Recherche avancée

Sur d’autres sites (12129)

• Survey of CD Image Formats

  30 avril 2013, par Multimedia Mike — General

  In the course of exploring and analyzing the impressive library of CD images curated at the Internet Archive’s Shareware CD collection, one encounters a wealth of methods for copying a complete CD image onto other media for transport. In researching the formats, I have found that many of them are native to various binary, proprietary CD programs that operate under Windows. Since I have an interest in interpreting these image formats and I would also like to do so outside of Windows, I thought to conduct a survey to determine if enough information exists to write processing tools of my own.

  Remember from my Grand Unified Theory of Compact Disc that CDs, from a high enough level of software abstraction, are just strings of 2352-byte sectors broken up into tracks. The difference among various types of CDs comes down to the specific meaning of these 2352 bytes.

  Most imaging formats rip these strings of sectors into a giant file and then record some metadata information about the tracks and sectors.

  ISO
  This is perhaps the most common method for storing CD images. It’s generally only applicable to data CD-ROMs. File images generally end with a .iso extension. This refers to ISO-9660 which is the standard CD filesystem.

  Sometimes, disc images ripped from other types of discs (like Xbox/360 or GameCube discs) bear the extension .iso, which is a bit of a misnomer since they aren’t formatted using the ISO-9660 filesystem. But the extension sort of stuck.

  BIN / CUE
  I see the BIN & CUE file format combination quite frequently. Reportedly, a program named CDRWIN deployed this format first. This format can handle a mixed mode CD (e.g., starts with a data track and is followed by a series of audio tracks), whereas ISO can only handle the data track. The BIN file contains the raw data while the CUE file is a text file that defines how the BIN file is formatted (how many bytes in a sector, how many sectors to each individual track).

  CDI
  This originates from a program called DiscJuggler. This is extremely prevalent in the Sega Dreamcast hobbyist community for some reason. I studied the raw hex dumps of some sample CDI files but there was no obvious data (mostly 0s). There is an open source utility called cdi2iso which is able to extract an ISO image from a CDI file. The program’s source clued me in that the metadata is actually sitting at the end of the image file. This makes sense when you consider how a ripping program needs to operate– copy tracks, sector by sector, and then do something with the metadata after the fact. Options include : 1) Write metadata at the end of the file (as seen here) ; 2) write metadata into a separate file (seen in other formats on this list) ; 3) write the data at the beginning of the file which would require a full rewrite of the entire (usually large) image file (I haven’t seen this yet).

  Anyway, I believe I have enough information to write a program that can interpret a CDI file. The reason this format is favored for Dreamcast disc images is likely due to the extreme weirdness of Dreamcast discs (it’s complicated, but eventually fits into my Grand Unified Theory of CDs, if you look at it from a high level).

  MDF / MDS
  MDF and MDS pairs come from a program called Alcohol 120%. The MDF file has the data while the MDS file contains the metadata. The metadata is in an opaque binary format, though. Thankfully, the Wikipedia page links to a description of the format. That’s another image format down.

  CCD / SUB / IMG
  The CloneCD Control File is one I just ran across today thanks to a new image posted at the IA Shareware Archive (see Super Duke Volume 2). I haven’t found any definitive documentation on this, but it also doesn’t seen too complicated. The .ccd file is a text file that is pretty self-explanatory. The sample linked above, however, only has a .ccd file and a .sub file. I’m led to believe that the .sub file contains subchannel information while a .img file is supposed to contain the binary data. So this rip might be incomplete (nope, the .img file is on the page, in the sidebar ; thanks to Phil in the comments for pointing this out). The .sub file is a bit short compared to the Archive’s description of the disc’s contents (only about 4.6 MB of data) and when I briefly scrolled through, it didn’t look like it contains any real computer data. So it probably is just the disc’s subchannel data (something I glossed over in my Grand Unified Theory).

  CSO
  I have dealt with the CISO (compressed ISO) format before. It’s basically the same as a .iso file described above except that each individual 2048-byte data sector is compressed using zlib. The format boasts up to 9 compression levels, which shouldn’t be a big surprise since that correlates to zlib’s own compression tiers.

  Others
  Wikipedia has a category for optical disc image formats. Of course, there are numerous others. However, I haven’t encountered them in the wild for the purpose of broad image distribution.

• ffmpeg API muxing h264 endoced frames to mkv

  24 mars 2017, par Pawel K

  Hi I’m having some problems with muxing h264 encoded frames into mkv container using code of ffmpeg-3.2.4.
  I have ended up with the following code that is a mashup of code found on SO and muxing.c example of ffmpeg :
  (and yes I am aware that it is ugly, no errors checked etc. it is meant to be like that for clarity :) )

  char *filename = "out.mkv";
  
  const uint8_t SPS[] = { 0x67, 0x42, 0x40, 0x1F, 0x96, 0x54, 0x02, 0x80, 0x2D, 0xD0, 0x0F, 0x39, 0xEA };
  
  const uint8_t PPS[] = { 0x68, 0xCE, 0x38, 0x80 };
  
  int fps = 5;
  
  
  
  typedef struct OutputStream
  
  {
  
     AVStream *st;
  
     AVCodecContext *enc;
  
  
  
     /* pts of the next frame that will be generated */
  
     int64_t next_pts;
  
     int samples_count;
  
     AVFrame *frame;
  
     AVFrame *tmp_frame;
  
     float t, tincr, tincr2;
  
     struct SwsContext *sws_ctx;
  
     struct SwrContext *swr_ctx;
  
  } OutputStream;
  
  
  
  static void avlog_cb(void *s, int level, const char *szFmt, va_list varg)
  
  {
  
     vprintf(szFmt, varg);
  
  }
  
  
  
  void main()
  
  {
  
     AVOutputFormat *fmt;
  
     AVFormatContext *formatCtx;
  
     AVCodec *audio_codec;
  
     AVCodec *video_codec;
  
     OutputStream video_st = { 0 };
  
     OutputStream audio_st = { 0 };
  
     av_register_all();
  
  
  
     av_log_set_level(AV_LOG_TRACE);
  
     //av_log_set_callback(avlog_cb);
  
  
  
     //allocate output and format ctxs
  
     avformat_alloc_output_context2(&formatCtx, NULL, NULL, filename);
  
     fmt = formatCtx->oformat;
  
  
  
     //allocate streams
  
     video_codec = avcodec_find_encoder(fmt->video_codec);
  
     video_st.st = avformat_new_stream(formatCtx, NULL);
  
     video_st.st->id = 0;
  
  
  
     AVCodecContext *codecCtx =  avcodec_alloc_context3(video_codec);
  
     fmt->video_codec = AV_CODEC_ID_H264;
  
     video_st.enc = codecCtx;
  
  
  
     codecCtx->codec_id = fmt->video_codec;
  
     codecCtx->bit_rate = 400000;
  
     codecCtx->width  = 1080;
  
     codecCtx->height = 720;
  
     codecCtx->profile = FF_PROFILE_H264_CONSTRAINED_BASELINE;
  
     codecCtx->level = 31;
  
  
  
     video_st.st->time_base = (AVRational){ 1, fps };
  
     codecCtx->time_base = video_st.st->time_base;
  
     codecCtx->gop_size = 4;
  
     codecCtx->pix_fmt = AV_PIX_FMT_YUV420P;
  
  
  
     //open video codec
  
     codecCtx->extradata_size = 24;
  
     codecCtx->extradata = (uint8_t *)av_malloc(codecCtx->extradata_size);
  
     uint8_t extra_data_array[] = { 0x01, SPS[1], SPS[2], SPS[3], 0xFF, 0xE1, 0xc0, 0, 0x42, 0x40, 0x1F, 0x96, 0x54, 0x02, 0x80, 0x2D, 0xD0, 0x0F, 0x39, 0xEA, 0x03, 0xCE, 0x38, 0x80 };
  
     memcpy(codecCtx->extradata, extra_data_array, codecCtx->extradata_size);
  
  
  
     AVCodecContext *c = video_st.enc;
  
     AVDictionary *opt = NULL;
  
     avcodec_open2(c, video_codec, &opt);
  
     avcodec_parameters_from_context(video_st.st->codecpar, c);
  
  
  
     //open output file
  
     avio_open(&formatCtx->pb, filename, AVIO_FLAG_WRITE);
  
  
  
     //write header
  
     int res = avformat_write_header(formatCtx, NULL);
  
  
  
     //write frames
  
  
  
     // get the frames from file
  
     uint32_t u32frameCnt = 0;
  
  
  
     do
  
     {
  
        int8_t i8frame_name[64] = "";
  
  
  
        uint8_t  *pu8framePtr = NULL;
  
        AVPacket pkt = { 0 };
  
  
  
        av_init_packet(&pkt);
  
        sprintf(i8frame_name, "frames/frame%d.bin", u32frameCnt++);
  
        //reading frames from files
  
        FILE *ph264Frame = fopen(i8frame_name, "r");
  
        if(NULL == ph264Frame)
  
        {
  
           goto leave;
  
        }
  
  
  
        //get file size
  
        fseek(ph264Frame, 0L, SEEK_END);
  
        uint32_t u32file_size = 0;
  
        u32file_size = ftell(ph264Frame);
  
        fseek(ph264Frame, 0L, SEEK_SET);
  
  
  
        pu8framePtr = malloc(u32file_size);
  
        uint32_t u32readout = fread(pu8framePtr, 1, u32file_size, ph264Frame);
  
  
  
        //if the read frame is a key frame i.e. nalu hdr type = 5 set it as a key frame
  
        if(0x65 == pu8framePtr[4])
  
        {
  
           pkt.flags = AV_PKT_FLAG_KEY;
  
        }
  
        pkt.data = (uint8_t *)pu8framePtr;
  
        pkt.size = u32readout;
  
        pkt.pts  = u32frameCnt;
  
        pkt.dts  = pkt.pts;
  
  
  
        av_packet_rescale_ts(&pkt, c->time_base, video_st.st->time_base);
  
        pkt.stream_index = video_st.st->index;
  
        av_interleaved_write_frame(formatCtx, &pkt);
  
        free(pu8framePtr);
  
        fclose(ph264Frame);
  
     }
  
     while(1);
  
  leave:
  
  
  
     av_write_trailer(formatCtx);
  
     av_dump_format(formatCtx, 0, filename, 1);
  
     avcodec_free_context(&video_st.enc);
  
     avio_closep(&formatCtx->pb);
  
     avformat_free_context(formatCtx);
  
  }

  It can be compiled with the following command line (after adding headers) :

  gcc file.c -o test_app -I/usr/local/include -L/usr/local/lib -lxcb-shm -lxcb -lX11 -lx264 -lm -lz -pthread -lswresample -lswscale -lavcodec -lavformat -lavdevice -lavutil

  The files that are read are valid annexB stream (valid as in it’s playable in vlc after concatenating into file) it is a Constrained Baseline 3.1 profile H264 and it comes from an IPcam’s interleaved RTCP/RTP stream (demuxed)

  The result is ... well I don’t see the picture. I get only black screen with the progress bar and timer running. I don’t know if I do something wrong with setting up the codecs and streams, or it’s just wrong timestamps.
  I know I got them wrong in some manner but I don’t understand that fully yet (how to calculate the correct presentation times), i.e. the stream and the codec both contain time_base field, and then I know that the sample rate of the video is 90kHz and the frame rate is 5 fps

  On top of it all the examples I’ve found have to some extend deprecated parts that change the flow/meaning of the application and that doesn’t help at all so thus If anyone could help I would appreciate it (I think not only me I would guess)

  Regards, Pawel

• FFmpeg stream extraction modifies subtitles [closed]

  21 mai 2024, par user18812922

  I have a video with the following ffprobe output :

  


  Input #0, matroska,webm, from 'video.mkv':
  Metadata:
    title           : Video - 01
    creation_time   : 2021-07-14T02:49:59.000000Z
    ENCODER         : Lavf58.29.100
  Duration: 00:22:57.28, start: 0.000000, bitrate: 392 kb/s
  Chapters:
    Chapter #0:0: start 0.000000, end 86.169000
      Metadata:
        title           : Opening
    Chapter #0:1: start 86.169000, end 641.266000
      Metadata:
        title           : Part A
    Chapter #0:2: start 641.266000, end 651.359000
      Metadata:
        title           : Eyecatch
    Chapter #0:3: start 651.359000, end 1286.160000
      Metadata:
        title           : Part B
    Chapter #0:4: start 1286.160000, end 1356.355000
      Metadata:
        title           : Ending
    Chapter #0:5: start 1356.355000, end 1376.876000
      Metadata:
        title           : Preview
  Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt709), 854x480 [SAR 1280:1281 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn (default)
      Metadata:
        DURATION        : 00:22:56.959000000
  Stream #0:1(eng): Audio: vorbis, 48000 Hz, stereo, fltp (default)
      Metadata:
        title           : English [FLAC 2.0]
        DURATION        : 00:22:57.278000000
  Stream #0:2(jpn): Audio: vorbis, 48000 Hz, stereo, fltp
      Metadata:
        title           : Japanese [FLAC 2.0]
        DURATION        : 00:22:57.276000000
  Stream #0:3(eng): Subtitle: ass (ssa)
      Metadata:
        title           : Signs and Songs [FMA1394/Redc4t]
        DURATION        : 00:22:51.090000000
  Stream #0:4(eng): Subtitle: ass (ssa)
      Metadata:
        title           : English [FMA1394/Redc4t]
        DURATION        : 00:22:51.090000000
  Stream #0:5(eng): Subtitle: hdmv_pgs_subtitle (pgssub), 1920x1080
      Metadata:
        title           : Full English Retail
        DURATION        : 00:22:51.120000000
  Stream #0:6: Attachment: ttf
      Metadata:
        filename        : 8bitoperator.ttf
        mimetype        : application/x-truetype-font
  Stream #0:7: Attachment: ttf
      Metadata:
        filename        : Cabin-Bold.ttf
        mimetype        : application/x-truetype-font
  Stream #0:8: Attachment: ttf
      Metadata:
        filename        : calibrib.ttf
        mimetype        : application/x-truetype-font
  Stream #0:9: Attachment: ttf
      Metadata:
        filename        : daniel_0.ttf
        mimetype        : application/x-truetype-font
  Stream #0:10: Attachment: ttf
      Metadata:
        filename        : DEATH_FONT.TTF
        mimetype        : application/x-truetype-font
  Stream #0:11: Attachment: ttf
      Metadata:
        filename        : Dominican.ttf
        mimetype        : application/x-truetype-font
  Stream #0:12: Attachment: ttf
      Metadata:
        filename        : gishabd.ttf
        mimetype        : application/x-truetype-font
  Stream #0:13: Attachment: ttf
      Metadata:
        filename        : PATRICK_0.TTF
        mimetype        : application/x-truetype-font
  Stream #0:14: Attachment: ttf
      Metadata:
        filename        : Qlassik-Medium.ttf
        mimetype        : application/x-truetype-font
Unsupported codec with id 98304 for input stream 6
Unsupported codec with id 98304 for input stream 7
Unsupported codec with id 98304 for input stream 8
Unsupported codec with id 98304 for input stream 9
Unsupported codec with id 98304 for input stream 10
Unsupported codec with id 98304 for input stream 11
Unsupported codec with id 98304 for input stream 12
Unsupported codec with id 98304 for input stream 13
Unsupported codec with id 98304 for input stream 14


  


  I am trying to extract the subtitles, edit them and reattach them to the video.
(I need my program to do that so I don't want to use other software)

  


  Command 1

  


  ffmpeg -i video.mkv -map 0:3 -c:s ssa subs.ass
ffmpeg -i video.mkv -i subs.ass -map 0 -map -0:s -map 1 -c copy out.mkv


  


  Command 2

  


  ffmpeg -i video.mkv -map 0:3 subs.ass
ffmpeg -i video.mkv -i subs.ass -map 0 -map -0:s -map 1 -c copy out.mkv


  


  Command 3

  


  ffmpeg -i video.mkv -map 0:3 subs.srt
ffmpeg -i video.mkv -i subs.srt -map 0 -map -0:s -map 1 -c copy out.mkv


  


  Command 4

  


  ffmpeg -i video.mkv -map 0:3 subs.srt
ffmpeg -i subs.srt subs.ass
ffmpeg -i video.mkv -i subs.ass -map 0 -map -0:s -map 1 -c copy out.mkv


  


  Command 5

  


  ffmpeg -i video.mkv -map 0:3 subs.ass
ffmpeg -i subs.ass subs.srt
ffmpeg -i video.mkv -i subs.srt -map 0 -map -0:s -map 1 -c copy out.mkv


  


  The problem

  


  After extraction the subtitles seem to be really quick, meaning they are displayed and disappear really quickly.

  


  For example the first subtitle is as follows in srt :

  


  1&#xA;00:00:03,100 --> 00:00:03,560&#xA;<font face="Dominican" size="77" color="#f7f7f7">Within the spreading darkness</font>&#xA;

  


  Now, in srt it also has wrong size but I assume that's because of the conversion from ass to srt.

  


  If I reattach the subtitle file in the video and open it, it is displayed and disappears way too fast and it doesn't match the original subtitles in the video.

  


  (ie, the original video subtitles are showing for at least a second)

  


  Expected behaviour

  


  The subtitles should be displayed for the same duration as the original subtitles.

  


  NOTE

  


  It's my first question for ffmpeg related issues so feel free to ask me for anything else you may need.

  


  UPDATE 1

  


  I realized that the subtitles were ok for the timings as they had the same line multiple times, so the problem for not playing is something else.

  


  Example of the file

  


  1&#xA;00:00:03,100 --> 00:00:03,560&#xA;<font face="Dominican" size="77" color="#f7f7f7">Within the spreading darkness</font>&#xA;&#xA;2&#xA;00:00:03,560 --> 00:00:04,650&#xA;<font face="Dominican" size="77" color="#f7f7f7">Within the spreading darkness</font>&#xA;&#xA;3&#xA;00:00:04,650 --> 00:00:05,100&#xA;<font face="Dominican" size="77" color="#f7f7f7">Within the spreading darkness</font>&#xA;

  


  So the problem is that VLC doesn't show more than the first subtitle.

  


  The strange thing is when I use the below command

  


  ffmpeg -i video.mkv -i subs.srt -map 0 -map -0:s -map 1 -c copy -c:s subrip out.mkv


  


  Then more lines of the subtitle (but not all) play.

  


  It stops at the 17th line.

  


  I believe that's an encoder's problem ? but I really don't know.

  


  Also what I noticed is that VLC stops the subtitles but Windows Media Player (Windows 11 version) display the subtitles correctly even after the 17th line.

  


  BUT, if I add subtitles from another video they are played correctly in both VLC and Windows Media Player.

  


  Update 2
As @Gyan said in his answer I should use the following command

  


  ffmpeg -i video.mkv -map 0:3 -c:s copy subs.ass


  


  But then if I attach the subs again with

  


  ffmpeg -i video.mkv -i subs.ass -map 0 -map -0:s -map 1 -c copy -c:s ass out.mkv


  


  The subtitles show up to 17th line in both VLC and Windows Media Player.

  


  or

  


  ffmpeg -i video.mkv -i .\subs.ass -map 0 -map -0:s -map 1 -c copy out.mkv


  


  The subtitles do not show up at all. (Not even in Windows Media Player)