Not a complete answer yet but FLVMeta and a partial reading of Adobe's spec are beginning to shine light on things. From an FLVMeta full dump the tags or sections of data look like this:
--- Tag #1019 at 0xCBEB5 (835253) --- Tag type: audio Body length: 213 Timestamp: 124957 * Sound type: stereo * Sound size: 16 * Sound rate: 44 * Sound format: AAC Previous tag size: 224 --- Tag #1020 at 0xCBF99 (835481) --- Tag type: video Body length: 1201 Timestamp: 124960 * Video codec: AVC * Video frame type: inter frame Previous tag size: 1212 --- Tag #1021 at 0xCC459 (836697) --- Tag type: audio Body length: 225 Timestamp: 124980 * Sound type: stereo * Sound size: 16 * Sound rate: 44 * Sound format: AAC Previous tag size: 236 --- Tag #1022 at 0xCC549 (836937) --- Tag type: video Body length: 542 Timestamp: 125000 * Video codec: AVC * Video frame type: inter frame Previous tag size: 553
So you could read the header into one file, put all the tags into 1 file each, then reconstruct however many input files into however many output files you wanted. Each "tag" I'd call a block, but it's a chunk of data. You don't have to manipulate them in real time. Each has a timestamp, you just have to put them together in that order and don't split a tag across files.
I wish FLVMeta had more useful output for moving things around under program control like tab or comma-delimited data. Maybe even create an SQLite database for each project, put all the audio tags in one table, video in another, script in another. Maybe I'll do that yet since it's open source and on Github. It'd be simpler if flvs weren't big-endian and I'm on a little-endian machine. All integers are big-endian, like on a Mac.