* [FFmpeg-devel] [PATCH 0/1] avcodec/h264_parser: fix start of packet for some broken
@ 2024-03-26 15:09 Nicolas Gaullier
2024-03-26 15:09 ` [FFmpeg-devel] [PATCH 1/1] avcodec/h264_parser: fix start of packet for some broken streams Nicolas Gaullier
2024-05-24 15:10 ` [FFmpeg-devel] [PATCH 0/1] avcodec/h264_parser: fix start of packet for some broken Nicolas Gaullier
0 siblings, 2 replies; 3+ messages in thread
From: Nicolas Gaullier @ 2024-03-26 15:09 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Nicolas Gaullier
This is a patch from my patch serie https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10999
Maybe it is easier to review it this way, independantly.
This patch shows some benefits by itself, but most importantly, it is required for my patch serie to avoid any regression with some invalid streams.
This patch is active in mpegts/h264 when the NAL Access Unit Delimiter is missing the zero_byte (= a invalid stream case).
In such a case, if it happens that the last data byte from the previous frame is a null byte, this byte is "kidnaped" to form the full NAL_AUD...
This is not good, but even worser, with my patch serie above applied, it means that the start of the editunit is in the previous frame,
which means the pts has to be taken in it, which is not the expected behaviour in such a missleading scenario.
Michael sent me a sample from the wild but it can't be shared, so here it is:
I have another sample of my own with NAL_AUD missing zero_byte similarly, but it is missing the ending null byte,
so I have patched/inserted the null byte (I shrinked the adaptation field) to show how the code behave.
Sample original (invalid NAL_AUDs):
https://0x0.st/Xs9Q.ts
Same sample modified to exhibit the issue (invalid NAL_AUDs + an available null ending byte at 0x291F):
https://0x0.st/Xs9j.ts
I use this simple command line and then compare the xml, it seems quite clear:
ffprobe xxx.ts -show_packets -show_data -print_format xml
Nicolas Gaullier (1):
avcodec/h264_parser: fix start of packet for some broken streams
libavcodec/h264_parser.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
* [FFmpeg-devel] [PATCH 1/1] avcodec/h264_parser: fix start of packet for some broken streams
2024-03-26 15:09 [FFmpeg-devel] [PATCH 0/1] avcodec/h264_parser: fix start of packet for some broken Nicolas Gaullier
@ 2024-03-26 15:09 ` Nicolas Gaullier
2024-05-24 15:10 ` [FFmpeg-devel] [PATCH 0/1] avcodec/h264_parser: fix start of packet for some broken Nicolas Gaullier
1 sibling, 0 replies; 3+ messages in thread
From: Nicolas Gaullier @ 2024-03-26 15:09 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Nicolas Gaullier
---
libavcodec/h264_parser.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 94cfbc481e..6b721ec253 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -124,7 +124,16 @@ static int h264_find_frame_end(H264ParseContext *p, const uint8_t *buf,
if (nalu_type == H264_NAL_SEI || nalu_type == H264_NAL_SPS ||
nalu_type == H264_NAL_PPS || nalu_type == H264_NAL_AUD) {
if (pc->frame_start_found) {
- i++;
+ /* Some streams in the wild are missing the zero_byte at the NAL_AUD:
+ * it is following just afterwards.
+ * To avoid any accidental borrowing of a byte in the previous frame
+ * (which would return a negative index and indicate that fetch_timestamps
+ * has to get the pts from the previous frame),
+ * better have the start of packet strictly aligned.
+ * To make it a more general rule, just test the following three bytes are null.
+ */
+ i += 1 + (!p->is_avc && state == 5 && i == 3 && nalu_type == H264_NAL_AUD &&
+ buf_size >= 9 && !AV_RB24(buf + 5));
goto found;
}
} else if (nalu_type == H264_NAL_SLICE || nalu_type == H264_NAL_DPA ||
--
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [FFmpeg-devel] [PATCH 0/1] avcodec/h264_parser: fix start of packet for some broken
2024-03-26 15:09 [FFmpeg-devel] [PATCH 0/1] avcodec/h264_parser: fix start of packet for some broken Nicolas Gaullier
2024-03-26 15:09 ` [FFmpeg-devel] [PATCH 1/1] avcodec/h264_parser: fix start of packet for some broken streams Nicolas Gaullier
@ 2024-05-24 15:10 ` Nicolas Gaullier
1 sibling, 0 replies; 3+ messages in thread
From: Nicolas Gaullier @ 2024-05-24 15:10 UTC (permalink / raw)
To: ffmpeg-devel
>Envoyé : mardi 26 mars 2024 16:10
>
>This is a patch from my patch serie https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10999
>Maybe it is easier to review it this way, independantly.
>This patch shows some benefits by itself, but most importantly, it is required for my patch serie to avoid any regression with some invalid streams.
>
>This patch is active in mpegts/h264 when the NAL Access Unit Delimiter is missing the zero_byte (= a invalid stream case).
>In such a case, if it happens that the last data byte from the previous frame is a null byte, this byte is "kidnaped" to form the full NAL_AUD...
>This is not good, but even worser, with my patch serie above applied, it means that the start of the editunit is in the previous frame, which means the pts has to be taken in it, which is not the expected behaviour in such a missleading >scenario.
>
>Michael sent me a sample from the wild but it can't be shared, so here it is:
>I have another sample of my own with NAL_AUD missing zero_byte similarly, but it is missing the ending null byte, so I have patched/inserted the null byte (I shrinked the adaptation field) to show how the code behave.
>
>Sample original (invalid NAL_AUDs):
>https://0x0.st/Xs9Q.ts
>Same sample modified to exhibit the issue (invalid NAL_AUDs + an available null ending byte at 0x291F):
>https://0x0.st/Xs9j.ts
>
>I use this simple command line and then compare the xml, it seems quite clear:
>ffprobe xxx.ts -show_packets -show_data -print_format xml
>
>Nicolas Gaullier (1):
> avcodec/h264_parser: fix start of packet for some broken streams
>
> libavcodec/h264_parser.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
Ping ?
_______________________________________________
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-05-24 15:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-26 15:09 [FFmpeg-devel] [PATCH 0/1] avcodec/h264_parser: fix start of packet for some broken Nicolas Gaullier
2024-03-26 15:09 ` [FFmpeg-devel] [PATCH 1/1] avcodec/h264_parser: fix start of packet for some broken streams Nicolas Gaullier
2024-05-24 15:10 ` [FFmpeg-devel] [PATCH 0/1] avcodec/h264_parser: fix start of packet for some broken Nicolas Gaullier
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