I have an issue with FLV stream generating. I've developed DVR system, an it should be able to stream video in FLV format (to play it on Actionscript NetStream). I receive video from encoder in raw H264 NAL units (0x00 0x00 0x00 0x01 ), also I can recognize is encoded frame IDR or non-IDR.
My solution to create FLV stream (based on Adobe spec: Video File Format Specification Version 10) was:
wait for IDR frame;
put FLV header
put PrevTagSize(0)
put FLV tag with video tag VIDEODATA with AVCVIDEODATA
put PrevTagSize
repeat steps 4,5 till end of streaming.
Stream looks good, and can be playable by ffplay, mplayer, vlc, etc.
But not played by player based on Actionscript NetStream.
So, I've get raw h264 data and convert it to FLV using ffmpeg:
ffmpeg -f h264 -i d1.h264 -vcodec copy -f flv d1.flv
and try to compate both flv's my and ffmpeg's.
First of all I see that ffmpeg adds AVC sequence header, immediately after FLV header.
I've started to do the same, but NetStream still not support my stream, and also another players ceased to play it.
Ok, then I've continue to compare flv's.
Now I see that NAL unit headers in ffmpeg's coded FLV a bit changed, but I can't understand what the meaning of the changes. I read many specs, but nothing helpful.
Did anybody can clarify me this?
Fo example my NAL units looks so:
00 00 00 01 XX XX ... - for all units
FFmpeg NALs:
00 00 [14 BA] 61 9A ... - non IDR (two bytes variable)
00 00 [7A 02] 65 88 ... - IDR (two bytes variable)
00 00 00 40 06 05 ... - SEI
Is there added some counter or anything else?
Will be happy to see any ideas, links, etc.
Try to use following command to do the work:
ffmpeg -y -i test.flv -vcodec copy -vbsf h264_mp4toannexb test.h264
You will got a vlc playable .h264 file, all NAL is begin with 00 00 00 01.
There are two common H.264 bitstream packing formats.
Annex B contains start codes: 00 00 01
MP4 is length prefixed XX XX XX XX
You are creating annex B but it seems like you need mp4 packing format (length prefixed) for FLV.
You have to remove (00) 00 00 01 and add the length as prefix.
Related
I am a new to linux/u-boot and just generally reading and writing to specific registers.
I have a KSZ9897 Ethernet switch, and my goal is to use u-boot i2c commands to set bits [15:13] to 001 to put the switch in the proper test mode.
The following screenshot is of the register that I am trying to read/write to:
KSZ9897 datasheet
The slave address of this part is 1011_111 = 0x5F
The address of the 16 bit register I am trying to read/write from is [0xN112-0xN113]
The PHY register is 0x09 (I am not sure how this fits in to the picture, but that may be the reason I am having issues)
using u-boot, I am sending the following command:
#i2c md 0x5F 0xN112.2 0x10
It reads back the following:
0000: 00 98 97 00 00 00 00 00 00 00 00 00 00 00 00 4c ...............L
My suspicion is that this is just reading the first 16 addr values starting at 0x0000. I know this because the 98 and 97 values match up with the default values that should be at address 0x0001 and 0x0002.
Can anyone tell me what I am doing wrong here and how I can access register 0x09? I think i am using the proper u-boot syntax, but clearly something is not right here. any help would be much appreciated.
The i2c command is wrong, because the third parameter must be a hexadecimal number and N is not hexa, the switch datasheet tells that:
Address field “N” specifies the portnumber. Valid values for “N” are 1 to 7 for some registers, 6 to 7 for MAC port specific registers, and 0 to 5 for PHYspecific registers.
You should be writing something like this: i2c md 0x5f 0x1112 1 , the last parameter is the number of bytes you read.
I take copy bytes dump using my Ubuntu os(MBR sector) following command.
dc3dd if=/dev/sda of=x cnt=1 ssz=512 hash=sha256 mlog=hashes
And I convert it to hexdump using following command.
hexdump x > hex_x
I receive out put like this .
I have some experts hep to analysis this hex_dump. I need to know what are the benefit of getting MBR hex dump and what kind of thing can be do using it ? (Eg: can I tell my system os like information analyzing this ? )
Need to know ,are there any commands or tools to more deep analyzing and convert this hexdump to human readable way ?
Q. what are the benefit of getting MBR hex dump and what kind of thing can be done using it?
A. Microsoft says:
The MBR contains a small amount of executable code called the master boot code, the disk signature, and the partition table for the disk.
The master boot code and disk signatures aren't very useful for someone (investigator). However the partition table gives a lot of information, and it can be used to extract information, in scenarios, where OS is corrupted or not booting and MBR can be used to investigate disk drive and operating system.
Sample Partition Table Record: (taken from an MBR, using HEX editor)
80 20 21 00 07 7E 25 19 00 08 00 00 00 38 06 00
Each hexadecimal value has some specific meaning, for instance:
80 => Partition type, Active
20 21 00 => Partition’s starting sector, Cylinder-Head-Sector (CHS)
07 => File System, NTFS
7E 25 19 => Partition’s ending sector, CHS
00 08 00 00 => Starting sector
00 38 06 00 => Size of the partition, 199 MiB
You can read them in detail in Table 1.2 Partition Table Fields, at official site.
Q. are there any commands or tools to more deep analyzing and convert this hexdump to human readable way?
A. You can use any HEX editor, like Hex Editor Neo or Active Disk Editor. These editors will help you in understanding MBR, but there is no magic tool available to to convert hexdump into human readable format (based on my knowledge).
PS: The question is pretty old, I wasn't available earlier so please accept late answer... :)
Is there a way to convert MessagePack response on Charles/MITM to JSON?
I have a response from https://[...]/application/x-msgpack
Raw mode reads it:
xdd\xb8\xbd\xc9? \x03\xa2Xe\xccO\xc2O\xd6"\x06\x91\xcfB\x9c\xed\x0fl
Hex mode reads it:
0000000010 06 91 cf 42 9c ed 0f 6c 2e 14 ae f1 da 2d 34 e9 ...B...l.....-4.
Hex mode contains contains nonsense at the end of every line.
Other modes could not parse and fall back to Raw mode.
If I fail to give you any other info, let me know.
If you can decode it in Python (e.g. using Kaitai Struct), you can implement a mitmproxy contentview to display it in a human-readable way:
https://github.com/mitmproxy/mitmproxy/blob/master/examples/simple/custom_contentview.py
https://github.com/mitmproxy/mitmproxy/tree/master/mitmproxy/contentviews
(if you go the kaitai struct route - we'd also be more than happy for a PR!)
I'm trying to write a MIDI parser, but I'm reaching a MIDI event that isn't documented in the official documentation (namely http://www.midi.org/techspecs/midimessages.php).
In one of the MIDI files that I have, I notice that immediately after a note-on event of 81 70 90 3c 00, I get the following bytes: 00 43 1e. However, I have not seen any documentation about 0x43 acting as a MIDI event identifier. How should I interpret 0x43, and where can I find more information about that?
Edit: The MIDI is interpretable, because I've loaded it up into Logic Pro without issues. Additionally, my interpretation up to the 0x43 has been accurate.
81 70 90 3c 00 00 43 1e
81 70: delta time (240 ticks)
90 3c 00: Note-On message (actually note off)
00: delta time
43 1e: Note-On message, using running status.
The MIDI Specification says:
RUNNING STATUS
For Voice and Mode messages only. When a Status byte is received and processed, the receiver will remain in that status until a different Status byte is received. Therefore, if the same Status byte would be repeated, it can optionally be omitted so that only the Data bytes need to be sent. Thus, with Running Status, a complete message can consist of only Data bytes.
Running Status is especially helpful when sending long strings of Note On/Off messages, where "Note On with Velocity of 0" is used for Note Off.
Status bytes always have the most significant bit set (80–FF), while Data bytes always have it clear (00–7F). Therefore, it is always possible to distinguish between them.
I am attempting to read constant (or initilization) strings from an iPhone Mach-O binary file. I understand that the 3 relevant segment.sections are _TEXT._cstring _TEXT._ustring and _DATA._cfstring. Howver, even though I know the string information is stored in these three blocks of data, which I have extracted, I can not make any sense of it, and it all looks like garbage - I do not see any recognizable character strings. Can anyone shed some light on this and give me an idea of what steps need to be take to read the string data?
I have looked at some code (GetAddrOfConstantCFString() from http://llvm.org/svn/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp), but again, couldn't quite relate it to what I see in the binaries.
In my case the sizes of the sections in question are:
__TEXT.__cstring (99 K-bytes)
__TEXT.__ustring (<200 bytes)
__DATA.__cfstring (29 K-bytes)
To give you an idea, the first 32 bytes of the __cfstring section, which I though would contain the actual strings looks like this:
Dump _DATA._cfstring
00 00 00 00 c8 07 00 00 74 02 0d 00 15 00 00 00
00 00 00 00 c8 07 00 00 8c 02 0d 00 01 00 00 00
...
Thanks a lot for your help!
Well, I've found the answer.
1) the files are generally encrypted (this can be tested with otool -l prog_file|grep -i crypt ). Not all sections are encrypted but usually the first block including _TEXT._text (prog code) and _TEXT._cstring are. The _DATA._cfstring section was not encrypted in my case.
2) as expected __cfstring consists of 16-byte structures (NSConstantString), where the 3rd word is a pointer to memory where _TEXT._cstring is loaded. The 4th word is the length.
So in real life the trick is to decrypt the file first, and then all is visible and accessible. I still didn't get around doing it properly, but dumped a piece of memory in gdb, which then replaced the relevant section in the file.