Archived copy. This page was recovered from the Internet Archive snapshot of /display/AQuA/Diagnosing FLV problems using FLVmeta's flvdump taken on 2013-07-16. The original wiki at wiki.opf-labs.org is being decommissioned.

Diagnosing FLV problems using FLVmeta's flvdump

Created by clare wf on Apr 12, 2011 · last edited by Roger G. Coram · on Apr 13, 2011 (view history) · 5 versions

One line summary	Deconstruct the FLV at the top level using flvdump and see if it is valid.
Detailed description	Used FLVmeta package which contained the flvdump programme, which was able to walk through the FLV file and check container was valid. For damaged files this spots blocks of data with invalid FLVTAG values (217, as opposed to 8, 9 and 18 meaning audio, video and data). Checking against the spec. shows that this is not a valid FLV (http://en.wikipedia.org/wiki/Flash_Video, http://download.macromedia.com/f4v/video_file_format_spec_v10_1.pdf Annex E). Only diagnoses the presence of the issue. Not sure is flvdump is stopping at the first bad block, or if bad blocks can be skipped. Further analysis would help ascertain repair options, if any.
Solution champion	Andrew Jackson
Git link	https://github.com/openplanets/AQuA/tree/master/gormley-flash
Evaluation Notes	Requires additional scripting to run solution over complete collection Possible that bad records could be skipped, and correct data identified after bad records in the file Second stage: fix broken records? Compare with Roger's migration approach to see if both solutions identify the same files as broken (i.e. validate the approaches) Solution specific to FLV, but general approach and liklihood of deconstruction code for different container formats suggests the approach will be applicable more widely if not the specific implementation
Detailed Evaluation	Not a resolution but provides a more direct indication of the problem. We'll need to verify that the same issue is apparent over a larger dataset. If it is indeed the case we could potentially begin to investigate recovering data from each file. Further analysis of the files will be necessary, possibly involving contact with the original supplier (i.e. if the strange frame-headers are indeed software-specific artifacts they may be able to provide input). Not a resolution but provides a more direct indication of the problem. We'll need to verify that the same issue is apparent over a larger dataset. If it is indeed the case we could potentially begin to investigate recovering data from each file. Further analysis of the files will be necessary, possibly involving contact with the original supplier (i.e. if the strange frame-headers are indeed software-specific artifacts they may be able to provide input).
Issue	Player stops part way through some of the performances
Tool (link)	http://code.google.com/p/flvmeta/ (http://code.google.com/p/flvmeta/source/browse/branches/1.0.x/flvdump.c)