On 2021/04/19 5:25, Marton Balint wrote:
On Sat, 17 Apr 2021, Mao Hata wrote:
According to ISO/IEC 13818-1, private_stream_1 is a synchronous
(has PTS/DTS) stream. Asynchronous one is private_stream_2.
Which section describes this?
Also keep in mind that code was added so that AV_CODEC_ID_SMPTE_KLV is
handled in mpegts, and SMPTE RP 217 promotes the usage of
private_stream_1, so I don't think this can be simply changed.
Regards,
Marton
Thank you for your reply. And I was not considering SMPTE (I misread the
word "KLV" just an abbreviation for "Key-Length-Value"). Oh... I
withdraw this patch.
The reason I created the patch was to fix the problem: when I transcode
a transport stream based on ARIB-STD-B24, the PTS/DTS is removed from
private_stream_1 streams, and, conversely, it is added to private_stream_2.
"ISO/IEC 13818-1 Table 2-17 - PES packet" (sorry, the table number may
have been shifted) defines the conditions under which PTS/DTS can exist
as follows:
>if (stream_id != program_stream_map
> && stream_id != padding_stream
> && stream_id != private_stream_2
> && stream_id != ECM
> && stream_id != EMM
> && stream_id != program_stream_directory
> && stream_id != DSMCC_stream
> && stream_id != ITU-T Rec. H.222.1 type E stream) {
So, private_stream_2 can not insert PTS/DTS. In addition, "ARIB-STD-B24,
VOLUME3, Chapter5" defines private_stream_1 as "Synchronized PES"
(mainly used for subtitles, with PTS/DTS inserted) and
private_stream_2 as "Asynchronous PES" (mainly used for superinpose, no
PTS/DTS inserted).
From these things, I misunderstood like that " PTS/DTS is generally
inserted for private_stream_1, so the `if (stream_id ==
STREAM_ID_PRIVATE_STREAM_1)` statement (I patched) must be a mistake! " ...
Anyway, as I read the related code, I now understand that the problem
should be solved specifically for ARIB-based transport stream (at
"mpegts.c" or so.).
Thank you again.
_______________________________________________
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".
