noirotm / flvmeta

FLV Metadata Editor

FLVMeta - FLV Metadata Editor

About

flvmeta is a command-line utility aimed at manipulating Adobe(tm) Flash Video files (FLV), through several commands, only one of which can be used for each invocation of the program.

Features

Metadata injection

This program has the ability to compute and inject a variety of values in the onMetaData event tag, including keyframe indices used by most video players to allow random-access seeking, notably for HTTP pseudo-streamed files via a server-side module, by having the client send the file offset looked up for the nearest desired keyframe. Tools such as flvmeta must be used in the case the initial encoding process is unable to inject those metadata.

It can also optionally inject the onLastSecond event, used to signal the end of playback, for example to revert the player software to a 'stopped' state.

File information and metadata dumping

flvmeta also has the ability to dump metadata and full file information to standard output, in a variety of textual output formats, including XML, YAML, and JSON.

File validity checking

Finally, the program can analyze FLV files to detect potential problems and errors, and generate a textual report in a raw format, or in XML. It has the ability to detect more than a hundred problems, going from harmless to potentially unplayable, using real world encountered issues.

Performance

flvmeta can operate on arbitrarily large files, and can handle FLV files using extended (32-bit) timestamps. It can guess video frame dimensions for all known video codecs supported by the official FLV specification.

Its memory usage remains minimal, as it uses a two-pass reading algorithm which permits the computation of all necessary tags without loading anything more than the file's tags headers in memory.

Installation

See the INSTALL.md file for build and installation instructions.

Authors

Main developer

• Marc Noirot [email protected]

Contributors

I would like to thank the following contributors:

• Neutron Soutmun [email protected] - spelling fixes, patches and Debian package maintenance
• Eric Priou [email protected] - support and MacOSX builds
• Zou Guangxian [email protected] - VP60 related bug fix
• [email protected] - malformed metadata related bug fix
• Robert M. Hall, II [email protected] - sample files to implement extended timestamp support
• [email protected] - extended timestamp related bug report
• Anton Gorodchanin [email protected] - command line and AVC bugfixes

Acknowledgements

The FLVMeta source package includes and uses the following software:

• the libyaml YAML parser and emitter (http://pyyaml.org/wiki/LibYAML).

License

FLVMeta is provided "as is" with no warranty. The exact terms under which you may use and (re)distribute this program are detailed in the GNU General Public License, in the file LICENSE.md.

See the CHANGELOG.md file for a description of major changes in this release.

See the file TODO for ideas on how you could help us improve FLVMeta.

flvmeta's Issues

Incorrect large file support

Hello.

I tried to use flvmeta 1.1.2 with file bigger than 2Gb in windows. It cant handle it because stat returns st_size as long.

I changed stat to _stat32i64. And all works fine now.

The stat call is used on Windows in the --check command.

A more portable approach is needed.

Bug in flvmeta: Unaddressable Accesses

Hello,

I recently discovered an input that causes flvmeta.exe to read two invalid pointers.

The input is attached - tested under Windows 10 with the following command line:
flvmeta.exe -F invalid_ptrs
invalid_ptrs.zip

SEGV in function xml_on_metadata_tag_only, src/dump_xml.c:271

POC:
flvmeta_poc2.zip

# ./flvmeta 'flvmeta_poc2'
ASAN:SIGSEGV
=================================================================
==41400==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7ffff6eb105a bp 0x7fffffffe0e0 sp 0x7fffffffd870 T0)
    #0 0x7ffff6eb1059  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x47059)
    #1 0x447581 in xml_on_metadata_tag_only /d/prog/8flvmeta.afl/src/dump_xml.c:271
    #2 0x4525ec in flv_parse /d/prog/8flvmeta.afl/src/flv.c:506
    #3 0x440ba6 in dump_metadata /d/prog/8flvmeta.afl/src/dump.c:160
    #4 0x405e59 in main /d/prog/8flvmeta.afl/src/flvmeta.c:385
    #5 0x7ffff6ac082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #6 0x4075a8 in _start (/d/p/aflasan/8.flvmeta+0x4075a8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==41400==ABORTING

This bug was found by NESA Lab.

Batch mode

FLVmeta currently lacks the possibility to work on several files when it is invoked.

Here I propose the creation of a so-called "batch mode" in which flvmeta will work on a list of files instead of a single file.

Triggering batch mode on will be done by two different ways:

1. sending a list of lines via stdin, each line containing one file path, file names specified on the command line will be ignored
2. using the -b/--batch option, where all files specified on the command line will be interpreted as input files

Obviously, this operation mode will only work where it makes sense to use it, in the check and update commands.

check command

It will alter its behaviour so filenames will be displayed in the text mode reporting, and create XML reports with several file entries. The number of errors/warnings will be global to the list of files.

update command

Every file specified will be updated in place, and the operation will continue until the last file is updated, even in the case of errors.
Errors will be displayed as usual.

heap-use-after-free via the function flvmeta/src/flv.c:375:21 in flv_close was detected

Hello, I would like to bring to your attention that I have encountered a potential issue in the new version about the flvmeta 1.2.2 0d3eb28.I'm not sure if this is. This observation was made during testing on Ubuntu 18.04. Thank you for your understanding.

compiler with asan

mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS="-fsanitize=address"
make

poc：https://github.com/hanxuer/crashes/raw/main/flvmeta/01/poc
reproduce： ./flvmeta/build/src/flvmeta ./poc

Asan report

==129869==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000000010 at pc 0x000000539f2c bp 0x7ffc37b92ee0 sp 0x7ffc37b92ed8
READ of size 8 at 0x604000000010 thread T0
    #0 0x539f2b in flv_close /flvmeta/flvmeta/src/flv.c:375:21
    #1 0x53bce3 in flv_parse /flvmeta/flvmeta/src/flv.c:525:17
    #2 0x52c487 in dump_metadata /flvmeta/flvmeta/src/dump.c:180:14
    #3 0x53c9cb in main /flvmeta/flvmeta/src/flvmeta.c:385:50
    #4 0x7faea13ddc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
    #5 0x41c7f9 in _start (/flvmeta/flvmeta/build/src/flvmeta+0x41c7f9)

0x604000000010 is located 0 bytes inside of 40-byte region [0x604000000010,0x604000000038)
freed by thread T0 here:
    #0 0x4dc4e0 in __interceptor_free.localalias.0 (/flvmeta/flvmeta-cov/build/src/flvmeta+0x4dc4e0)
    #1 0x539f79 in flv_close /flvmeta/flvmeta/src/flv.c:378:9
    #2 0x539e83 in flv_read_video_tag /flvmeta/flvmeta/src/flv.c:250:13
    #3 0x53bc93 in flv_parse /flvmeta/flvmeta/src/flv.c:523:22
    #4 0x52c487 in dump_metadata /flvmeta/flvmeta/src/dump.c:180:14
    #5 0x53c9cb in main /flvmeta/flvmeta/src/flvmeta.c:385:50
    #6 0x7faea13ddc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310

previously allocated by thread T0 here:
    #0 0x4dc6b0 in malloc (/flvmeta/flvmeta/build/src/flvmeta+0x4dc6b0)
    #1 0x53771a in flv_open /flvmeta/flvmeta/src/flv.c:52:42
    #2 0x53b5d9 in flv_parse /flvmeta/flvmeta/src/flv.c:480:22
    #3 0x52c487 in dump_metadata /flvmeta/flvmeta/src/dump.c:180:14
    #4 0x53c9cb in main /flvmeta/flvmeta/src/flvmeta.c:385:50
    #5 0x7faea13ddc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310

SUMMARY: AddressSanitizer: heap-use-after-free /flvmeta/flvmeta-cov/src/flv.c:375:21 in flv_close
Shadow bytes around the buggy address:
  0x0c087fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c087fff8000: fa fa[fd]fd fd fd fd fa fa fa fa fa fa fa fa fa
  0x0c087fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==129869==ABORTING

gdb backtrace

gef➤  bt
#0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff76847f1 in __GI_abort () at abort.c:79
#2  0x00007ffff76cd837 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff77faa7b "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff76d48ba in malloc_printerr (str=str@entry=0x7ffff77fc6e8 "free(): double free detected in tcache 2") at malloc.c:5342
#4  0x00007ffff76dc0ed in _int_free (have_lock=0x0, p=0x693250, av=0x7ffff7a2fc40 <main_arena>) at malloc.c:4195
#5  __GI___libc_free (mem=0x693260) at malloc.c:3134
#6  0x00000000004223d3 in flv_close (stream=0x693260) at /home/hanxuerr/myfuzz/target_program/flvmeta/flvmeta/src/flv.c:378
#7  0x000000000042394c in flv_parse (file=<optimized out>, parser=<optimized out>) at /flvmeta/flvmeta/src/flv.c:525
#8  0x000000000041a41d in dump_metadata (options=0x652530 <main.options>) at /flvmeta/flvmeta/src/dump.c:180
#9  0x0000000000424937 in main (argc=<optimized out>, argv=<optimized out>) at /flvmeta/flvmeta/src/flvmeta.c:385

source code

void flv_close(flv_stream * stream) {
    if (stream != NULL) {
        if (stream->flvin != NULL) {
            fclose(stream->flvin);
        }
        free(stream); // flv.c:378
    }
}


else if (tag.type == FLV_TAG_TYPE_VIDEO) {
            retval = flv_read_video_tag(parser->stream, &vt);
            if (retval == FLV_ERROR_EOF) {
                flv_close(parser->stream);  //flv.c:525
                return retval;
            }

incorrect file duration

As reported here: https://groups.google.com/forum/?hl=en_US&fromgroups=#!topic/flvmeta-discuss/V5_RWyTi8ts

flvmeta should use the last frame's actual type to compute its duration.

Support for Adobe Video specification 10.1 extensions

FLVmeta should support the 10.1 spec extensions: filtering, encryption, and generation and reading of XMP metadata (http://www.adobe.com/devnet/xmp.html).

The dump command must output all possible filtering and encryption info.

We must take care of this info when updating the files so we do not compute invalid metadata from encrypted video or audio data.

Eventually encrypt/decrypt files ourselves, but this might represent a lot of work.

SEGV in function xml_amf_data_dump, src/dump_xml.c:151

POC:
flvmeta_poc1.zip

# ./flvmeta 'flvmeta_poc1'
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<associativeArray xmlns="http://schemas.flvmeta.org/AMF0/1.0/">
  <entry name="duration">
    <number value="1.868"/>
  </entry>
  <entry name="width">
    <number value="640"/>
  </entry>
  <entry name="heigh">
ASAN:SIGSEGV
=================================================================
==28167==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000030 (pc 0x7ffff6b63071 bp 0x0000004b1340 sp 0x7fffffffdc20 T0)
    #0 0x7ffff6b63070  (/lib/x86_64-linux-gnu/libc.so.6+0xc3070)
    #1 0x7ffff6b650a5 in __strftime_l (/lib/x86_64-linux-gnu/libc.so.6+0xc50a5)
    #2 0x445efe in xml_amf_data_dump /d/prog/8flvmeta.afl/src/dump_xml.c:151
    #3 0x446600 in xml_amf_data_dump /d/prog/8flvmeta.afl/src/dump_xml.c:121
    #4 0x4475a0 in dump_xml_amf_data /d/prog/8flvmeta.afl/src/dump_xml.c:305
    #5 0x4475a0 in xml_on_metadata_tag_only /d/prog/8flvmeta.afl/src/dump_xml.c:272
    #6 0x4525ec in flv_parse /d/prog/8flvmeta.afl/src/flv.c:506
    #7 0x440ba6 in dump_metadata /d/prog/8flvmeta.afl/src/dump.c:160
    #8 0x405e59 in main /d/prog/8flvmeta.afl/src/flvmeta.c:385
    #9 0x7ffff6ac082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #10 0x4075a8 in _start (/d/p/aflasan/8.flvmeta+0x4075a8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==28167==ABORTING

This bug was found by NESA Lab.

invalid JSON dump

Hi,

this is probably very easy to fix for someone who knows C and flvmeta's code a little bit.

We're using Red5 to record audio/video streams and the problem described here is probably also a problem there. Anyway, Red5 writes the following file which is basically only the header because something crashed along the way. And I'm trying to use flvmeta to check in such cases:

$ flvmeta --dump --json foo-v0.flv  # JSON formatted for your convenience
{
  "duration": 0,
  "server": "Red5",
  "creationdate": "Sun Apr 19 16:39:36 UTC 2015",
  "videocodecid": "avc1",
  "canSeekToEnd": true,
  "videodatarate": -nan,
  "noaudiocodec": 0
}

As you can see, there's invalid JSON: "videodatarate": -nan.

Here's the file so that you can check yourselves (base64-encoded so that I can paste it here):

$ base64 foo-v0.flv
RkxWAQEAAAAJAAAAABIAALgAAAAAAAAAAgAKb25NZXRhRGF0YQgAAAAAAAhkdXJhdGlvbgAAAAAA
AAAAAAAGc2VydmVyAgAEUmVkNQAMY3JlYXRpb25kYXRlAgAcU3VuIEFwciAxOSAxNjozOTozNiBV
VEMgMjAxNQAMdmlkZW9jb2RlY2lkAgAEYXZjMQAMY2FuU2Vla1RvRW5kAQEADXZpZGVvZGF0YXJh
dGUA//gAAAAAAAAADG5vYXVkaW9jb2RlYwAAAAAAAAAAAAAACQAAAMMJAAAuAAAAAAAAABcAAAAA
AU0AH//hABpnTUAfllQFAX/LgKhAAAADAEAAAAynaEiagAEABGjONSAAAAA5

Thanks.

Add gettext support

French and english languages should be supported for a start, more later.

The Windows build should default to english for simplicity.

CMake and Autotools should be able to build flvmeta with gettext support.

Metadata injection

FLVmeta must allow the injection of AMF0 metadata directly into any random point in a FLV file, using an XML file as input.

Just like the --update command, if only one file is specified, it is updated in-place, whereas specifying a second file leaves the original file untouched.

The XML file contains not only AMF0 metadata as specified by the amf0.xsd schema, but also directives allowing to specify the action to apply.

Allowed actions are:

• insert: to insert a metadata tag at the given position
• replace: to replace an existing metadata tag with the data from the XML file
• delete: to delete metadata from the FLV file
• update: to add values to an existing metadata tag, with the constraint that the existing metadata are an associative array or an object.

Several such actions are permitted in one XML file.
Each action operates either on a decimal address in the file, exactly representing the offset of an existing tag, either on a decimal timestamp in milliseconds, either on the name of a metadata tag which must exist in the FLV file (only the first one matches, unless a "match all" attribute is present), either with the special name EOF representing the end of the file.

In order to create entirely correct FLV files, meaning with well calculated metadata, flvmeta then invokes itself recursively at the end of the operation with an update command in order to recompute the onMetadata tag, with the --preserve option used in order not to lose any metadata inserted by the previous operation.

The new command --inject/ -I is used by specifying an optional argument, the name of the XML file containing metadata to inject. Alternatively, XML metadata can be read on stdin.

Examples:
flvmeta --inject metadata.xml input.flv output.flv
flvmeta -I input.flv < metadata.xml

Memory allocation failure in xml_on_metadata_tag_only() at dump_xml.c:271

Memory allocation failure in xml_on_metadata_tag_only() at dump_xml.c:271

Memory allocation failure in the flvmeta at function xml_on_metadata_tag_only in dump_xml.c:271.

Environment

Ubuntu 18.04, 64 bit
FLVMeta 1.2.1

Steps to reproduce

1. download file

wget https://github.com/noirotm/flvmeta/archive/refs/tags/v1.2.1.tar.gz
tar -zxvf v1.2.1.tar.gz

2. compile libming with ASAN

cd flvmeta-1.2.1
export FORCE_UNSAFE_CONFIGURE=1
export LLVM_COMPILER=clang
CC=wllvm CXX=wllvm++ CFLAGS="-g -O0 -Wno-error" cmake -DCMAKE_C_COMPILER=wllvm -DCMAKE_CXX_COMPILER=wllvm++ -B obj-bc -G"Unix Makefiles" 
cd obj-bc
make

cd src
extract-bc flvmeta
clang -fsanitize=address flvmeta.bc -o flvmeta_asan

3. command for reproducing the error

./flvmeta_asan poc

Download poc:
flvmeta_memory-allocation-failure_dumpxml271.zip

ASAN report

root@a71b82b5d288:~/dataset/flvmeta-1.2.1/obj-bc/src# ./flvmeta_asan flvmeta_memory-allocation-failure_dumpxml271 
AddressSanitizer:DEADLYSIGNAL
=================================================================
==30124==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x000000489d7b bp 0x7fff17e62cb0 sp 0x7fff17e62440 T0)
==30124==The signal is caused by a READ memory access.
==30124==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x489d7b in __interceptor_strcmp.part.298 /root/LLVM/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:444
    #1 0x4fe908 in xml_on_metadata_tag_only /root/dataset/flvmeta-1.2.1/src/dump_xml.c:271:14
    #2 0x502563 in flv_parse /root/dataset/flvmeta-1.2.1/src/flv.c:506:26
    #3 0x4fd491 in dump_metadata /root/dataset/flvmeta-1.2.1/src/dump.c:160:14
    #4 0x502855 in main /root/dataset/flvmeta-1.2.1/src/flvmeta.c:385:50
    #5 0x7f8aa5304c86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
    #6 0x41b819 in _start (/root/dataset/flvmeta-1.2.1/obj-bc/src/flvmeta_asan+0x41b819)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /root/LLVM/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:444 in __interceptor_strcmp.part.298
==30124==ABORTING

Heap Buffer Overflow in get_bit() src/avc.c:43

Description of problem:
heap-buffer-overflow get_bit() of avc.c:43

How reproducible:
./flvmeta POC /dev/null

poc file: https://drive.google.com/file/d/1vNROOuVU37OOlJOMaNSkpX0DwhhZakLy/view?usp=sharing

=================================================================
==85591==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61500000fee1 at pc 0x0000004090be bp 0x7fff7d8f40f0 sp 0x7fff7d8f40e0
READ of size 1 at 0x61500000fee1 thread T0
    #0 0x4090bd in get_bit /home/puppet/test_object_video/flvmeta/src/avc.c:43
    #1 0x4091fa in exp_golomb_ue /home/puppet/test_object_video/flvmeta/src/avc.c:66
    #2 0x409266 in exp_golomb_se /home/puppet/test_object_video/flvmeta/src/avc.c:76
    #3 0x409646 in parse_sps /home/puppet/test_object_video/flvmeta/src/avc.c:194
    #4 0x409b56 in read_avc_resolution /home/puppet/test_object_video/flvmeta/src/avc.c:292
    #5 0x41ff91 in compute_avc_size /home/puppet/test_object_video/flvmeta/src/info.c:146
    #6 0x42006f in compute_video_size /home/puppet/test_object_video/flvmeta/src/info.c:164
    #7 0x4218eb in get_flv_info /home/puppet/test_object_video/flvmeta/src/info.c:433
    #8 0x42680b in update_metadata /home/puppet/test_object_video/flvmeta/src/update.c:272
    #9 0x41ed52 in main /home/puppet/test_object_video/flvmeta/src/flvmeta.c:388
    #10 0x7fdcb0df182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #11 0x403f68 in _start (/usr/local/bin/flvmeta+0x403f68)

0x61500000fee1 is located 0 bytes to the right of 481-byte region [0x61500000fd00,0x61500000fee1)
allocated by thread T0 here:
    #0 0x7fdcb1233602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x409ac3 in read_avc_resolution /home/puppet/test_object_video/flvmeta/src/avc.c:282
    #2 0x41ff91 in compute_avc_size /home/puppet/test_object_video/flvmeta/src/info.c:146
    #3 0x42006f in compute_video_size /home/puppet/test_object_video/flvmeta/src/info.c:164
    #4 0x4218eb in get_flv_info /home/puppet/test_object_video/flvmeta/src/info.c:433
    #5 0x42680b in update_metadata /home/puppet/test_object_video/flvmeta/src/update.c:272
    #6 0x41ed52 in main /home/puppet/test_object_video/flvmeta/src/flvmeta.c:388
    #7 0x7fdcb0df182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/puppet/test_object_video/flvmeta/src/avc.c:43 get_bit
Shadow bytes around the buggy address:
  0x0c2a7fff9f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fff9f90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fff9fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a7fff9fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a7fff9fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c2a7fff9fd0: 00 00 00 00 00 00 00 00 00 00 00 00[01]fa fa fa
  0x0c2a7fff9fe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fff9ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==85591==ABORTING

This vulnerability was triggered in get_bit() /flvmeta/src/avc.c:43

static uint8 get_bit(bit_buffer * bb) {
    uint8 ret;
    ret = (*(bb->current) >> (7 - bb->read_bits)) & 0x1;
    if (bb->read_bits == 7) {
        bb->read_bits = 0;
        bb->current++;
    }
    else {
        bb->read_bits++;
    }
    return ret;
}

Actual results:
crash

Expected results:
crash

NULL Pointer Dereference in xml_on_metadata_tag_only() at dump_xml.c:271

Tested in Ubuntu 18.04, 64bit, gcc 7.3.0, flvmeta (master 1c9cee8)

Triggered by
$ ./flvmeta $POC

POC file:
https://github.com/Marsman1996/pocs/blob/master/flvmeta/poc17-xml_on_metadata_tag_only-SEGV

ASAN info:

ASAN:DEADLYSIGNAL
=================================================================
==41446==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fa732fb5e1a bp 0x7ffe6e35d9f0 sp 0x7ffe6e35d150 T0)
==41446==The signal is caused by a READ memory access.
==41446==Hint: address points to the zero page.
    #0 0x7fa732fb5e19  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x59e19)
    #1 0x55ef074c05ed in xml_on_metadata_tag_only /home/ubuntu/Desktop/crashana/flvmeta/flvmeta-master/src/dump_xml.c:271
    #2 0x55ef074c6f58 in flv_parse /home/ubuntu/Desktop/crashana/flvmeta/flvmeta-master/src/flv.c:506
    #3 0x55ef074bc20c in dump_metadata /home/ubuntu/Desktop/crashana/flvmeta/flvmeta-master/src/dump.c:160
    #4 0x55ef074c908d in main /home/ubuntu/Desktop/crashana/flvmeta/flvmeta-master/src/flvmeta.c:385
    #5 0x7fa732b8cb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #6 0x55ef074aae19 in _start (/home/ubuntu/Desktop/crashana/flvmeta/flvmeta-master/bin_asan/bin/flvmeta+0x11e19)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x59e19) 
==41446==ABORTING

GDB info

Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31	../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or directory.
(gdb) bt
#0  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x000055555556363e in xml_on_metadata_tag_only ()
#2  0x0000555555566876 in flv_parse ()
#3  0x0000555555561468 in dump_metadata ()
#4  0x00005555555672f9 in main ()

Linker error, cannot find "isfinite" symbol

I am having issues building flvmeta on my FreeBSD machine. The issue is that the isfinite() function, declared in math.h, requires linking against libm.so to actually use the symbol:

[100%] Linking C executable flvmeta
ld: error: undefined symbol: __isfinite
>>> referenced by json.c
>>>               CMakeFiles/flvmeta.dir/json.c.o:(json_emit_number)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

I can work around this problem on my machine by editing src/CMakeLists.txt and adding this line somewhere:
target_link_libraries(flvmeta m)

which does add -lm to the linker opts as expected.

Unfortunately I know practically nothing about CMake, so I cannot contribute a patch for this that wouldn't possibly break other things :(

Add check JSON output format

This would be useful for projects such as https://github.com/patriksimek/node-flvmeta.

The --json / -j option would be used.