Transcript: Noisy introduced in audio stream.
Origin stream is OK:
Transcript stream has noisy:
The noisy comes from the transcoding for each piece, so it appears every 10s, when switching to next ts piece.
You can use VLC to play the index.m3u8 and reproduce this issue.
If change the fps to 25, the stutter is less but still exists.
Play transcript.zip by ffplay: ffplay -loglevel debug index.m3u8, the warning message is
[hls @ 0x144e076c0] HLS request for url '1455-overlay-b5c12e9c-53d9-4cac-ac4f-04f08a6c8637.ts', offset 0, playlist 0 [hls @ 0x144e076c0] Opening '1455-overlay-b5c12e9c-53d9-4cac-ac4f-04f08a6c8637.ts' for reading [mpegts @ 0x144e07c40] Continuity check failed for pid 17 expected 4 got 0 [mpegts @ 0x144e07c40] Continuity check failed for pid 0 expected 4 got 0 [mpegts @ 0x144e07c40] Continuity check failed for pid 4096 expected 4 got 0 [mpegts @ 0x144e07c40] Continuity check failed for pid 256 expected 11 got 0 [mpegts @ 0x144e07c40] Packet corrupt (stream = 0, dts = 1310932497). [hls @ 0x144e076c0] Packet corrupt (stream = 0, dts = 1310929494).
debug the ffplay by gdb, the Packet corrupt log print in
https://github.com/FFmpeg/FFmpeg/blob/1d55f548466516a6a4ed4cc67e118e1c29c6ae5a/libavformat/demux.c#L577-L581C78
if (pkt->flags & AV_PKT_FLAG_CORRUPT) {
av_log(s, AV_LOG_WARNING,
"Packet corrupt (stream = %d, dts = %s)%s.\n",
pkt->stream_index, av_ts2str(pkt->dts),
s->flags & AVFMT_FLAG_DISCARD_CORRUPT ? ", dropping it" : "");
the AV_PKT_FLAG_CORRUPT is set at:
https://github.com/FFmpeg/FFmpeg/blob/1d55f548466516a6a4ed4cc67e118e1c29c6ae5a/libavformat/mpegts.c#L2814-L2822
when demux failed the continuity check.
[mpegts @ 0x144e07c40] Continuity check failed for pid 17 expected 4 got 0 [mpegts @ 0x144e07c40] Continuity check failed for pid 0 expected 4 got 0 [mpegts @ 0x144e07c40] Continuity check failed for pid 4096 expected 4 got 0 [mpegts @ 0x144e07c40] Continuity check failed for pid 256 expected 11 got 0
- How TS
continuity checkworks?
https://github.com/ossrs/srs/blob/7951bf3bd63a33ec5bfddfba39f9d6e2d476e381/trunk/src/kernel/srs_kernel_ts.hpp#L406-L420
There is a 4-bit size continuity_counter field in TS packet, in range [0, 15], to keep the order of ts packets per pid.
when ffmpeg transcode the ts segment file, the countinuity_counter recount from 0 per pid. And I didn't find the ffmpeg cmd or filter to config the start counter, [0, 15], per pid for mpeg-ts format yet.
If countinuity_counter config is not the feature of ffmpeg then I need to mux the mpeg-ts packet by code.
- first, maintain a map[pid] = previous ts segmet's last
countinuity_counter; - add another queue to the oryx transcript task, which demux and mux the ts packets by recount
countinuity_counterfrom map[pid] + 1, and rewrite map[pid] by current ts segment's last packet.
-
Verify this issue
-
[x] dev a
countinuity_counterrecount app and apply totranscript.zip, then letVLCworks well.
Confirmed both the countinuity_counter (cc) and timestamp impact this issue.
Here is the cc fixed transcript sample:
The code to account cc manually:
https://gist.github.com/suzp1984/37a356a3fec4e69531ec10fbcb4a627f
compare transcript.zip and transcript_cc_fixed.zip in VLC.
The sound loss of "transcript.zip" is very obvious, while the sound of "transcript_cc_fixed.zip" is discontinuous between ts segments. The transcript_cc_fixed.zip only let cc count continually between ts, so I think if the timestamp between ts improved, I believe the sounds can play well.
the timestamp can be improved by choice 25 fps video source.
If change the fps to 25, the stutter is less but still exists.
Next action:
- [ ] More testing with 25 fps video source + cc recount improve.
- [ ] Edit timestamp of TS segment by code.
- [ ] Check ffmpeg doc found possible way to rewrite|config cc count and timestamp.
- [ ] Revalue the solutions whether fixed in
ffmpegororyx.
Another testing I did to verify the sound discontinuous problem, check above comment, the cc count continually between ts can fix the obvious problem, but still sound still not perfect.
I use the original.zip to reproduce the same audio stream problem.
here is the steps to reproduce:
- transcode the ts segments in original.zip
ffmpeg -i 1457-org-cfe71a34-a90d-4e3f-9ec8-b008223cc957.ts -c:v libx264 -profile:v main -preset:v medium -tune zerolatency -bf 0 -c:a copy -copyts -y aac_copy/1457-org-cfe71a34-a90d-4e3f-9ec8-b008223cc957.tstranscode the ts segment with similar method used inoryx, but the audio data is copy without transcode, the video data is transcoded without rendering srt file. apply above cmd to every ts segments, and copyindex.m3u8to target folderaac_copy/later. - play
aac_copy/index.m3u8inVLC, the audio stream stutter is reproduced so close to transcript.zip - apply
cccount to ts segments,aac_copy/*.ts:cp aac_copy/1454-org-024c7fd8-9b60-431c-9ef6-236518f00078.ts aac_copy_cc_fixed/1454-org-024c7fd8-9b60-431c-9ef6-236518f00078.tsthe first ts need not to fixed. run https://gist.github.com/suzp1984/37a356a3fec4e69531ec10fbcb4a627f to find the latest cc number for audio and video stream.go run . aac_copy_cc_fixed/1454-org-024c7fd8-9b60-431c-9ef6-236518f00078.tschange the video stream pid (256) and audio stream pid (257) new start count number according to above probe result. then rungo run aac_copy/1455-*.ts aac_copy_cc_fixed/1455-*.tsredo similar probe foraac_copy_cc_fixed/1455-*.ts:go run . aac_copy_cc_fixed/1455-*.ts. then do same job to1456-*.ts. - play
aac_copy_cc_fixed/index.m3u8inVLC, the stream works really well.
I know those steps are all did manually and so silly. I upload the result.
aac_copy.zip
is the result of step 1, which reproduce the audio stream stutter.
aac_copy_cc_fixed.zip
is the result of step 3, which apply cc fix to step 1, the audio stream stutter fixed.
Conclusion
The cc discontinuously between ts segments and audio stream transcode both contribute the audio stutter.
USE Restreamer its awesome