On 28-04-2019 04:15 PM, Nicolas George wrote:
Gyan (12019-04-28):
Corrupt streams in sufficiently intact containers (MP4, TS) so they can be
demuxed but decoder context fields are incomplete/invalid, so ffmpeg won't
streamcopy-mux them.
Depending on the exact situation, I would use a repair or analysis tool to
check them or supply an alternate esds..etc
And you want to just dump the packets payload in a file? With the ffmpeg
command-line?
Then I suggest to implement that as a ffmpeg option:
ffmpeg -dump_stream:0 stream0.bin -i damaged.mp4 -f null -
I'll try this but I don't think the command as presented will work because
a) there's no codec option set, so ffmpeg has to decode frames and that
will fail for damaged streams. But this can be quickly remedied by
adding -c copy
b) ffmpeg will call avformat_write_header for the output, which will
likely fail because of the aforementioned codec parameter issues. When
that happens, ffmpeg will exit and only the packets demuxed and flushed
up to that point will be present in the dumped file. This could possibly
be averted by providing a valid dummy input and mapping only that to the
output. However, I believe ffmpeg will then exit when that output is
marked as finished, but the dumped stream may not be because the main
transcode() loop isn't sensitive to it.
The pipeline for dumping damaged streams is identical to dumping valid
streams except for the part when timestamps are regulated and codec
fields validated for the target muxer, which is what my patch disables
for a single muxer that doesn't need them. I don't see much (any?)
"wasted" processing with my patch, relative to streamcopying a valid stream.
Gyan
_______________________________________________
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".
