From: "Dawid Kozinski/Multimedia \(PLT\) /SRPOL/Staff Engineer/Samsung Electronics" <d.kozinski@samsung.com> To: "'FFmpeg development discussions and patches'" <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v23 04/10] avformat/evc_demuxer: Added demuxer to handle reading EVC video files Date: Wed, 7 Jun 2023 18:30:14 +0200 Message-ID: <008601d9995d$56cf6160$046e2420$@samsung.com> (raw) In-Reply-To: > -----Original Message----- > From: Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung > Electronics <d.kozinski@samsung.com> > Sent: środa, 7 czerwca 2023 17:41 > To: 'FFmpeg development discussions and patches' <ffmpeg- > devel@ffmpeg.org> > Subject: RE: [FFmpeg-devel] [PATCH v23 04/10] avformat/evc_demuxer: Added > demuxer to handle reading EVC video files > > > > > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > > James Almer > > Sent: środa, 7 czerwca 2023 15:40 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v23 04/10] avformat/evc_demuxer: > > Added demuxer to handle reading EVC video files > > > > On 6/7/2023 10:36 AM, Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff > > Engineer/Samsung Electronics wrote: > > > > > > > > > > > >> -----Original Message----- > > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > > >> James Almer > > >> Sent: poniedziałek, 29 maja 2023 15:08 > > >> To: ffmpeg-devel@ffmpeg.org > > >> Subject: Re: [FFmpeg-devel] [PATCH v23 04/10] avformat/evc_demuxer: > > >> Added demuxer to handle reading EVC video files > > >> > > >> On 5/26/2023 7:31 AM, Dawid Kozinski wrote: > > >>> +static int get_temporal_id(const uint8_t *bits, int bits_size) { > > >>> + int temporal_id = 0; > > >>> + short t = 0; > > >>> + > > >>> + if (bits_size >= EVC_NALU_HEADER_SIZE) { > > >>> + unsigned char *p = (unsigned char *)bits; > > >>> + // forbidden_zero_bit > > >>> + if ((p[0] & 0x80) != 0) > > >>> + return -1; > > >>> + > > >>> + for (int i = 0; i < EVC_NALU_HEADER_SIZE; i++) > > >>> + t = (t << 8) | p[i]; > > >> > > >> I think this can be replaced with AV_RB16. > > >> > > >>> + > > >>> + temporal_id = (t >> 6) & 0x0007; > > >>> + } > > >>> + > > >>> + return temporal_id; > > >>> +} > > >> > > >> [...] > > >> > > >>> +static uint32_t read_nal_unit_length(const uint8_t *bits, int > > >>> +bits_size) { > > >>> + uint32_t nalu_len = 0; > > >>> + > > >>> + if (bits_size >= EVC_NALU_LENGTH_PREFIX_SIZE) { > > >>> + > > >>> + int t = 0; > > >>> + unsigned char *p = (unsigned char *)bits; > > >>> + > > >>> + for (int i = 0; i < EVC_NALU_LENGTH_PREFIX_SIZE; i++) > > >>> + t = (t << 8) | p[i]; > > >> > > >> AV_RB32. > > >> > > >>> + > > >>> + nalu_len = t; > > >>> + if (nalu_len == 0) // Invalid bitstream size > > >>> + return 0; > > >>> + } > > >>> + > > >>> + return nalu_len; > > >>> +} > > >> > > >> [...] > > >> > > >>> +static int evc_frame_merge_filter(AVBSFContext *bsf, AVPacket *out) { > > >>> + EVCMergeContext *ctx = bsf->priv_data; > > >>> + AVPacket *in = ctx->in; > > >>> + > > >>> + int free_space = 0; > > >>> + size_t nalu_size = 0; > > >>> + uint8_t *nalu = NULL; > > >>> + int au_end_found = 0; > > >>> + int err; > > >>> + > > >>> + err = ff_bsf_get_packet_ref(bsf, in); > > >>> + if (err < 0) > > >>> + return err; > > >>> + > > >>> + nalu_size = read_nal_unit_length(in->data, > > >> EVC_NALU_LENGTH_PREFIX_SIZE); > > >>> + if(nalu_size <= 0) { > > >>> + av_packet_unref(in); > > >>> + return AVERROR_INVALIDDATA; > > >>> + } > > >>> + > > >>> + nalu = in->data + EVC_NALU_LENGTH_PREFIX_SIZE; > > >>> + nalu_size = in->size - EVC_NALU_LENGTH_PREFIX_SIZE; > > >>> + > > >>> + // NAL unit parsing needed to determine if end of AU was found > > >>> + err = parse_nal_unit(nalu, nalu_size, bsf); > > >>> + if (err < 0) { > > >>> + av_log(bsf, AV_LOG_ERROR, "NAL Unit parsing error\n"); > > >>> + av_packet_unref(in); > > >>> + > > >>> + return err; > > >>> + } > > >>> + > > >>> + au_end_found = end_of_access_unit_found(bsf); > > >>> + > > >>> + free_space = ctx->au_buffer.capacity - ctx->au_buffer.data_size; > > >>> + while( free_space < in->size ) { > > >>> + ctx->au_buffer.capacity *= 2; > > >>> + free_space = ctx->au_buffer.capacity - > > >>> + ctx->au_buffer.data_size; > > >>> + > > >>> + if(free_space >= in->size) { > > >>> + ctx->au_buffer.data = av_realloc(ctx->au_buffer.data, > > >>> + ctx- > > >>> au_buffer.capacity); > > >>> + } > > >>> + } > > >>> + > > >>> + memcpy(ctx->au_buffer.data + ctx->au_buffer.data_size, > > >>> + in->data, > > >>> + in->size); > > >> > > >> This is including the Annex-B's nal_unit_lenght value into the > > >> assembled > > > packet. I > > >> assume libxevd expects this? Also, is it defined as part of the > > >> ISOBMFF encapsulation? Patch 07/10 does not seem to strip it. > > > > > > Could you expand on this topic? > > > What do you mean by "Patch 07/10 does not seem to strip it"? > > > Patch 7/10 expands the implementation of the MOV Muxer to support > > > the EVC stream. > > > The function ff_isom_write_evcc parses the received data, extracts > > > NAL units of types SPS, PPS, APS, SEI, and inserts their contents > > > into the corresponding elements of the arrays array, which is a > > > component of the EVCDecoderConfigurationRecord structure. > > > Additionally, the ff_isom_write_evcc function populates the relevant > > > fields of the EVCDecoderConfigurationRecord structure based on the > > > parsed SPS NAL unit data, and then calls the evcc_write function, > > > which writes the EVCDecoderConfigurationRecord to the stream. > > > > > > It seems that I don't understand what's wrong with our > > > implementation ( I mean MOV muxer for EVC) and it seems I need your > > > help in this matter. I need an explanation of what's wrong and what > > > should be done to fix > > the issue. > > > > I mean the packets that go into ISOBMFF Sample, not the evcc atom. Is > > the encapsulation supposed to include the nal_unit_length from Annex-B? > > The function mov_write_single_packet(s, pkt) receives packets containing the > Access Units (AU) of an EVC stream. Each AU consists of a sequence of NAL > units, each preceded by a 4-byte prefix that contains information about the > length of the NAL unit. The entire AU is then copied to AVIOContext using > avio_write(pb, pkt->data, size). > It seems to me that everything is okay. If I am mistaken, just let me know. As we have also completed all the fixes following your review this is the last thing blocking us from creating a new patchset. > > _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://protect2.fireeye.com/v1/url?k=64932a8f-05183fb9-6492a1c0- > > 74fe485cbff1-9eaddc0975cfe99c&q=1&e=9bd489fd-4417-4f27-9fc0- > > > e7d04e51de8c&u=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp > > eg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2023-06-07 16:30 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20230526103158eucas1p1e8b2adfc43aaf57c62e23e78571df817@eucas1p1.samsung.com> 2023-05-26 10:31 ` Dawid Kozinski 2023-05-29 13:07 ` James Almer 2023-06-07 13:36 ` Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics 2023-06-07 13:39 ` James Almer 2023-06-07 15:41 ` Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics 2023-06-07 16:30 ` Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics [this message] 2023-06-07 16:37 ` James Almer 2023-06-07 22:11 ` Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='008601d9995d$56cf6160$046e2420$@samsung.com' \ --to=d.kozinski@samsung.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git