Just one question : what is the size in bytes of the header of a .mp4 file ?
The goal is to fuzz just this header.
Thanks
Karl
It depends. ISO media container format (.mp4) uses a strusture of elements called atoms. It depends on the number of tracks, the H.264 encoding properties, the muxers also like to put their names in the file in a free atom.
Expect it to be at least 1 kByte. Anything over 4k is not very likely.
If you encounter the string mdat (header of the movie data atom), the file header is probably over.
Related
I would like to know what is the max size of the value length field for the VR OB and OW. I know that currently its 2^32(32 bit application).I want to know in 64 bit application it will be 64 bit? I referred dicom standard(DICOM PS3.5 2014c - Data Structures and Encoding). I did not get any clue. Since we want to store the huge non image data (more than 4gb) I would like to know if that is possible.
Thanks in advance.
Although the maximum size of an attribute is 0xfffffffe, in the image data attribute (0x7fe0, 0x0010) larger data can be stored by using an encapsulated transfer syntax. This effectively lets you split up your image data into multiple "items" called fragments. Each fragment also has a maximum size of 0xfffffffe, but there is no limitation to the number of fragments in the image data attribute.
Refer to chapter 5, annex A.4 "Transfer Syntaxes For Encapsulation of Encoded Pixel Data" of the DICOM Standard for detailed explanation.
If you use a library also take a look at their documentation, lots of libraries, for example dcmtk, do support splitting an image into multiple frames. Just look for keywords like fragment or encapsulation.
The maximum size of the tag is dictated by the DICOM standard, not by the CPU architecture on which the DICOM library is compiled or used.
At the moment the maximum size (in bytes) of a OB or OW tag is represented by a 32-bit wide value (minus 1 or 2 because 0xFFFFFFFF is reserved).
With the HTTP header Range clients can request only a certain range of bytes from a server.
GET myfile.jpg HTTP/1.1
"http://myhost"
Range=bytes=1000-1200
If the server supports this response feature and maybe even shows that by a Accept-Range header, the above request will return only the 200 bytes from byte 1000 onwards.
Is it possible to get usable parts from an JPG image with this method? Say the actual JPG measures 800x1197 pixels. What would have to be done in order to request only a sub image between the pixels 200x200 and 400x400?
To me it looks like it's only possible receive horizontally cut slices of the image. But this would already be better than getting the full image file. So in the example above I'd say one could try to download: the slice from 200 (y-axis) to 400 (y-axis) and then crop the result on the client side accordingly.
Assume we already know the content-length of the file as well as its actual image size, which may have been determined by a preceding HTTP request:
content length in bytes: 88073
jpg size: 800x1197
Which byte range would I have to request for this image? I assume that JPG has some meta data, which has to be taken in account as well. Or does the compression of jpg render this attempt impossible? It would be ok if the final cut out does not contain any metadata from the original.
But still it might be necessary to have an initial request, which takes some bytes from the beginning hoping to fetch the metadata. and based on this the actual byte range might be determined.
Would be very nice if someone could give me a hint how to approach this.
JPEG encodes compressed data in one or more scans. The scans do not indicate their length. You have to actually decode to get to the end of the scan. The scans span the entire image.
If the JPEG stream is progressively encoded you can read the stream blocks at at a time, decode the scans, update the output image, and get successively refined views of the image.
I am developing a scanner application in C++. Currently I am able to scan the documents and get the images in file transfer mode. But all the scanned documents have same size even though the content of the documents are different.
FileFormat:TWFF_TIFF
Pixel flavout: TWPF_CHOCOLATE
Xresoultion:75
Yresoultion:75
ICAP_UNITS: TWUN_INCHES
ICAP_PIXELTYPE: TWPT_GRAY
ICAP_BRIGHTNESS:0
ICAP_CONTRAST:0
ICAP_BITDEPTH: 8
Every time scanned image size as 327kb. Why would this be?
Also, how can I set JPEG_Compression. Does file transfer mode supports JPEG_compression?
Probably your scanner/driver is writing uncompressed TIFF files, so the file size depends only on the dimensions of the image. If each image is the same width & height, the resulting files will be the same size.
All the file-transfer stuff in TWAIN is implemented by the driver (not TWAIN itself) and all the features are optional. So you need to check if your scanner/driver supports JPEG compression when transferring TIFF files. It might, it might not.
You can try setting ICAP_COMPRESSION to TWCP_JPEG, after setting ICAP_IMAGEFILEFORMAT to TWFF_TIFF. Probably if both succeed you will get JPEG compression in your TIFFs, although it might be either "Old Style" JPEG or "New Style" JPEG. If you don't know what that means, you probably should find out.
I wrote a tool for this kind of experimenting, years ago, still maintained and free from Atalasoft: Twirl TWAIN Probe
Caution: Many scanners don't support File Transfer Mode (it is optional) and those that do may not support the TIFF file format (the only required file format is BMP!) If you need to support a wide variety of scanners, you'll have to use TWAIN's Native Transfer Mode or Memory Transfer Mode, and write the images to file yourself e.g. using LibTiff.
I have an original video coded at 20Mbps, 1920x1080, 30fps and want to convert it down to be 640x480 30fps at a range of (3 different) bitrates for use by Adobe Live Streaming.
Should I use ffmpeg to resize and encode at the 3 bitrates then use f4fpackager to create the f4m f4f and f4x files or just use ffmpeg to reduce the resolution and then f4fpackager to encode the relevant bitrates?
I've had several tries so far, but when encoded the videos seem to play at a much larger bitrate than they've been encoded at. For example, if I set up the OSMF to play from my webserver, I'd be expecting my best encoded video to play at 1,500kbps but it's way above that.
Has anyone had any experience of encoding for use like this?
I'm using the following options to f4fpackager
--bitrate=1428 --segment-duration 30 --fragment-duration 2
f4fpackager doesn't do any encoding, it does 2 things:
- fragment the mp4 files (mp4 -> f4f)
- generate a Manifest (f4m) file referencing all you fragmented files (f4f)
So the process is:
- transcode your source file in all the size/bitrate that you want to provide (eg: 1920x01080#4Mbps, 1280x720#2Mbps, etc)
- use f4fpackager to convert the mp4 to f4f (this is the fragmentation step)
- use f4fpackager to generate the Manifest.f4m referencing the files that you generated in the previous step
the --bitrate option of f4fpackager should match the value that you use with ffmpeg, this parameter is used to generate the manifest file with the correct bitrate value of each quality
how do people view encrypted pictures like on this wiki page? is there a special program to do it, or did someone decide to do some silly xor just make a point about ECB? im not a graphics person, so if there are programs to view encrypted pictures, what are they?
Encryption works on a stream of bytes. That is, it takes an array of bytes and outputs another array of bytes. Images are also just an array of bytes. We assign the "r" component of the top-left pixel to the first byte, the "g" component to the second byte, the "b" component to the third byte. The "r" component of the pixel next to that is the fourth byte and so on.
So to "encrypt" an image, you just take a byte array of the pixels in the first image, encrypt it (encryption usually doesn't change the number of bytes - apart from padding) and use those encrypted bytes as the pixel data for the second image.
Note that this is different from encrypting an entire image file. Usually an image file has a specific header (e.g. the JPEG header, etc). If you encrypted the whole file then the header would also be included and you wouldn't be able to "display" the image without decrypting the whole thing.
To view an encrypted image, the image has to be an uncompressed image format for example bmp.
PNG, JPEG and so on are compressed images so you wont't be able to display those. Also the imgae header has to be uncompressed.
If you want to encrypt pictures like this, just convert it to an uncompressed format, open it with an hex editor and save the image header. After that u can encrypt the image with AES/ECB.
At last you have to insert the original image header. Now you should be able to view the encrypted image.
It's not just a silly XOR (they can all use XOR) but yes, it's just there to emphasize that any scheme which converts the same input to the same output every time makes it easy to spot patterns that were present in the input. The image is there to show how easily we can spot Tux in the "encrypted" output. The author could have used any kind of data, but used an image because the human eye is very good at spotting patterns, so it makes a good example.
As the article says, better schemes use the output of the previous block to "randomize" the next block, so you can't see patterns in the output (a la the image on the right).