Não é uma resposta completa, mas a FLVMeta e uma leitura parcial das especificações da Adobe estão começando a esclarecer as coisas. De um despejo completo do FLVMeta, as tags ou seções de dados são assim:
--- 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
Assim, você poderia ler o cabeçalho em um arquivo, colocar todas as tags em um arquivo cada e, em seguida, reconstruir quantos arquivos de entrada em quantos arquivos de saída desejasse. Cada "tag" eu chamaria de bloco, mas é um pedaço de dados. Você não precisa manipulá-los em tempo real. Cada um tem um timestamp, você só precisa colocá-los juntos nessa ordem e não dividir uma tag entre os arquivos.
Eu gostaria que o FLVMeta tivesse uma saída mais útil para mover as coisas sob o controle do programa, como tabulação ou dados delimitados por vírgulas. Talvez até crie um banco de dados SQLite para cada projeto, coloque todas as tags de áudio em uma tabela, vídeo em outra, script em outra. Talvez eu faça isso ainda, já que é open source e no Github. Seria mais simples se flvs não fossem big-endian e eu estivesse em uma máquina little-endian. Todos os inteiros são big-endian, como em um Mac.