| 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) |