On Sun, 2 Aug 2020, Steven Liu wrote:
Martin Storsjö <mar...@martin.st> 于2020年8月2日周日 下午2:49写道：Since this test was added in ac22835db947e, it actually has been using segment type mpegts, contrary to what the test looks like it is supposed to test. --- tests/fate/hlsenc.mak | 2 +- tests/ref/fate/hls-fmp4 | 384 ++++++++++++++++++++-------------------- 2 files changed, 193 insertions(+), 193 deletions(-) diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak index d4ce26457d..a57450cd7c 100644 --- a/tests/fate/hlsenc.mak +++ b/tests/fate/hlsenc.mak @@ -89,7 +89,7 @@ tests/data/hls_fmp4.m3u8: TAG = GEN tests/data/hls_fmp4.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \ -f lavfi -re -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=5" -map 0 -codec:a mp2fixed \ - -hls_segment_type mpegts -hls_fmp4_init_filename now.mp4 -hls_list_size 0 \ + -hls_segment_type fmp4 -hls_fmp4_init_filename now.mp4 -hls_list_size 0 \ -hls_time 1 -hls_segment_filename "$(TARGET_PATH)/tests/data/hls_fmp4_%d.m4s" \ $(TARGET_PATH)/tests/data/hls_fmp4.m3u8 2>/dev/nullLGTM
Actually, it turns out that this change makes the test output dependent on the architecture - the attached change was generated on aarch64, but on x86_64 I'm getting a different result. Adding "-flags +bitexact" doesn't seem to help...
Right now I have no idea why the change of segment format has this effect and I'm not sure I have time to dig into it at the moment either - patch 3/3 is the important one for me.
// Martin _______________________________________________ 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".
