From: Nicolas Gaullier <nicolas.gaullier@cji.paris> To: ffmpeg-devel@ffmpeg.org Cc: Nicolas Gaullier <nicolas.gaullier@cji.paris> Subject: [FFmpeg-devel] [PATCH v2 0/5] avcodec/parser: fix fetch_timestamp in a scenario with unaligned packets Date: Fri, 1 Mar 2024 14:39:18 +0100 Message-ID: <20240301133923.1132924-1-nicolas.gaullier@cji.paris> (raw) This is the following of https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10843 The file submited by Michael highlighted 3 different and independent issues I missed in the first version: - some corrupt mpegts files are missing the zero_byte at the NAL, but a "full" NAL start including the zero_byte can be found just afterwards, so they can be identified. In some cases, there might be a terminal null byte at the end of the previous frame and thus it is "borrowed" by current code to form a complete, full NAL start: in such a case, the fix fetch_timestamp now get the pts of the previous pes, which is not expected. So, I've added a h264_parser patch (new patch 4) - the index may be negative even for the very first packet, despite pointing to no data, so I've added the "!s->frame_offset" condition to enable the "fetch timestamp in the past" patch - the mpegts demuxer has a "split packets" logic according to its max_packet_size, and in my understanding, the behavious of the current code does not look good, the cur_frame_arrays are fed with kind of "empty entries", which now raises an issue because some "past entries" are required to get proper timestamps from the previous frame, so this had to be fixed (new patch 1) : the entries of the splited packets should be merged to get consistent entries Patch 3: I forced the AVCodecParserContext offset to be positive. Patch 5: unchanged. Still not sure whether this patch is somewhat "required", "useless", or "bad". What possibly remains: as seen with some h264 broken streams in the wild, there might be other broken stream issues (hevc?). If such issues currently exists (but currently with no serious effect), there would be a regression in the PTS/DTS values. So any testing with corrupt streams beyond h264 is wellcome to see if other parsers require a fix (say a hack). For remembering, sample files and cover letter of the first version: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321819.html Nicolas Gaullier (5): avcodec/parser: merge packets from the same frame avcodec/parser: reindent after previous commit avcodec/parser: fix fetch_timestamp in a scenario with unaligned packets avcodec/h264_parser: fix start of packet for some broken streams lavf/demux: duplicate side_data in parse_packet() libavcodec/h264_parser.c | 11 +- libavcodec/parser.c | 29 ++-- libavformat/demux.c | 23 ++- tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +++++++++--------- tests/ref/fate/ts-demux | 8 +- 5 files changed, 131 insertions(+), 104 deletions(-) -- 2.30.2 _______________________________________________ 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 reply other threads:[~2024-03-01 13:39 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-01 13:39 Nicolas Gaullier [this message] 2024-03-01 13:39 ` [FFmpeg-devel] [PATCH v2 1/5] avcodec/parser: merge packets from the same frame Nicolas Gaullier 2024-03-03 22:06 ` Michael Niedermayer 2024-03-04 17:38 ` Nicolas Gaullier 2024-03-05 20:51 ` Michael Niedermayer 2024-03-01 13:39 ` [FFmpeg-devel] [PATCH v2 2/5] avcodec/parser: reindent after previous commit Nicolas Gaullier 2024-03-01 13:39 ` [FFmpeg-devel] [PATCH v2 3/5] avcodec/parser: fix fetch_timestamp in a scenario with unaligned packets Nicolas Gaullier 2024-03-01 13:39 ` [FFmpeg-devel] [PATCH v2 4/5] avcodec/h264_parser: fix start of packet for some broken streams Nicolas Gaullier 2024-03-01 13:39 ` [FFmpeg-devel] [PATCH v2 5/5] lavf/demux: duplicate side_data in parse_packet() Nicolas Gaullier 2024-03-01 13:49 ` James Almer 2024-03-01 13:54 ` James Almer
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=20240301133923.1132924-1-nicolas.gaullier@cji.paris \ --to=nicolas.gaullier@cji.paris \ --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