On Sun, Apr 11, 2021 at 5:51 PM Jan Ekström <jee...@gmail.com> wrote: > > On Sun, Apr 11, 2021 at 4:58 PM Jan Ekström <jee...@gmail.com> wrote: > > > > On Sun, Apr 11, 2021 at 4:25 PM magic xqq <x...@xqq.im> wrote: > > > > > > I have already tried to use st->stream_identifier directly in mpegtsenc.c > > > while handling arib_caption stream in mpegts_write_pmt() function. > > > > > > But in mpegtsenc.c, st->stream_identifier always provides > > > an incorrect value of 0, which should be 0x30 for arib_caption A profile. > > > > > > st->stream_identifier seems hasn't been copied correctly while remuxing > > > into > > > another mpegts stream. So I manually copied it. > > > > > > > Yes, AVStream::stream_identifier is not currently handled by ffmpeg.c. > > Not sure its addition was ever really thought thoroughly, and mostly > > added so that MPEG-TS reading clients could gain this value when > > reading data. Not even ffprobe.c is currently poking a stick at it. > > > > But quickly looking at things, you can map component_tag and > > component_id according to the ARIB caption profile, since your > > possibilities are: > > > > FF_PROFILE_ARIB_PROFILE_A => component tag 0x30-0x37, data_component_id = > > 0x0008 > > FF_PROFILE_ARIB_PROFILE_C => component_tag 0x87, data_component_id = 0x0012 > > > > The only issue is if you want to keep the exact same component tag, > > but that can be improved in ffmpeg.c by just passing it during stream > > copy into the output AVStream if it's nonzero (that is why it's > > identifier plus 1). Also probably we need an option to force it to > > something else if needed. In any case, I consider this somewhat > > separate from the remux case since I don't think you need to have the > > exact same id for the remux to be workable? Please note if I am > > mistaken. > > > > Then there's the extra info, I'll have to check the specs later today > > whether that contains anything dynamic. > > > > Best regards, > > Jan > > Alright, so that additional data structure is one byte large and > contains the following things: > > additional_arib_caption_info(){ > DMF bslbf(4) > Reserved bslbf(2) > Timing bslbf(2) > } > > DMF - (Display mode flag), with b1111 being the most common value "dynamic" > Timing - async|program sync|real time sync > > So I guess at the very least this would make sense to add into the > extradata. I do find it interesting though that libaribb24 doesn't > seem to require this data for valid decoding at all :D (although I > guess mostly the output timing and automated subtitle sub-stream > selection is affected by these values).
For context, just checked some random sample I had on hand: ARIB caption info: DMF: 0xa, reserved: 0x3, timing: 0x1 So "both caption streams are selectable/showable when both received and playing back a recording" (0b1010), reserved bits are nonzero, timing is PTS based ("program based" seems to mean that). Jan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".