mbox series

[FFmpeg-devel,v2,0/5] avcodec/parser: fix fetch_timestamp in a scenario with unaligned packets

Message ID 20240301133923.1132924-1-nicolas.gaullier@cji.paris
Headers show
Series avcodec/parser: fix fetch_timestamp in a scenario with unaligned packets | expand

Message

Nicolas Gaullier March 1, 2024, 1:39 p.m. UTC 
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(-)