On Mon, 12 Dec 2022, Chris Ribble wrote:
On Sun, Dec 11, 2022 at 2:34 PM Chris Ribble <chris.rib...@resi.io> wrote:
This looks great and I've confirmed it fixes the issue. I see the
warning on STDERR about ignoring the trun box: "Ignoring trun box with
zero sized samples", which is great.
Actually, this introduces a new issue when I try to transcode the
problematic mp4 and then segment it with the DASH muxer.
It appears that ignoring the trun box while reading the input affects
the segment alignment of the audio with the video.The durations jitter
around quite a bit and some of them are very long. The same problem
seems to exist whether I transcode or copy the audio.
Well, remuxing sparse audio packets certainly can cause issues. For a full
transcode, I did not expect that much difference, for the audio gaps you
should be able to generate silence with -af aresample=async=1 or similar.
Overall, I am not sure what to do here:
1) Simply revert original patch, and make it work same as before, and
accept that 0-sized packets can be generated by the MOV demuxer, or
fuzzed files can cause practically infinite loops (not that unusual for
multimedia formats)
2) Apply this patchset which makes the MOV demuxer ignore the 0-sized
packets and fixes the original fuzzing issue, but causing some strange
issues when remuxing or transcoding because the audio packets become
sparse.
3) Dig deeper what goes wrong with remuxing/reencoding with sparse audio.
Unfortunately I won't have time to do this.
Comments are welcome.
Thanks,
Marton
_______________________________________________
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".
