PDA

View Full Version : h264visa:free tool for h264/avc baseline profile analysis.


h264visa
20th October 2007, 13:31
I made a free tool(H264Visa) to analyze h264/AVC baseline stream(Download (http://h264visa.daydayup.info/files/H264Visa.zip)).
Originally I used it for H.264/AVC learning, but I find it can also be used for Mobile TV applications, some ipod videos or other videos using h.264 baseline profile codec. Now it is in beta version, I post it for your evaluations and your feedback.

the webpage for this tool is:
http://h264visa.daydayup.info
or
http://h264visa.googlepages.com/index.html

Here are the main features:
* Different file formats:
+ H.264 Byte Stream format(Annex B)
+ MP4 file formats.
+ mpeg2 ts file format(ISDB-T 1seg)
* I/P mb insight analysis, including:
+ ref list
+ mb type
+ intra/inter prediction info
+ LP filter strength info
+ I/P MB mode overlay display
* mb pixel info and display in all decoding stages, including:
+ Finally decoded pixels
+ Pixels before Deblocking Filter
+ Predicted Pixels
+ Pixels info from residual data
+ IDCT coefficients(not display mode)
* SPS/PPS info and self explanation by double-click.
* Dump decoded YUV output into file.
* Friendly UI, including Play/Pause/FF, etc.
* Small and faster.

h264visa
20th October 2007, 20:52
I attached the screenshot. waiting for your feedback.

bond
20th October 2007, 21:27
i cant get it to work with your sample .h264 file

when i open it, all that is shown is the sps/pps info. when i push play or step forward to get some more info it crashes

i am using winxp with a p3 processor

h264visa
21st October 2007, 04:11
Hi bond,

I tried on three computers(two P4, one Pentium M) on winxp, could not reproduce a crash.
Can you provide more info and the steps to reproduce it?

Thanks.

bond
21st October 2007, 10:53
- open tool
- open the test.h264
- push play

guada2
21st October 2007, 14:52
- h264visa : crash
- ESE tools: OK

h264visa
21st October 2007, 16:15
Hi bond/guada2,

I did more tests on my friends' machine, no crash reported.
All the test machines are using winxp sp2, but the CPUs are very different, RAWs > 512M.

Can you tell me your winxp version(sp1 or sp2), and language settings(english or other languages)?

Thanks.

bob0r
21st October 2007, 17:03
@bond, got link to your .264 sample?
Then ill try reproduce also.

Reuf Toc
21st October 2007, 17:32
I think the sample used by Bond is the one include in the H264Visa package.

Works fine here with Sempron 2800+ (SSE, SSE2, SSE3 & MMX), XP pro 32 bit

hank315
21st October 2007, 18:10
Just tested it with the supplied sample on a Core 2 Duo.

Windows XP pro 32 bit, SP2, runs OK.
Windows Vista Ultimate 64 bit, runs OK.

h264visa
22nd October 2007, 00:18
Yes, bond/guada2 were using the test.h264 sample file in the same package.

Thanks for the test, I am very glad at that H264visa even works on windows vista.

Do you have any ideas for new features? for example:
- support on main/extended profile,
- GUI,
- Speed,
- Bugs

Thanks.

fsinapsi
22nd October 2007, 15:53
Yes, bond/guada2 were using the test.h264 sample file in the same package.
test.h264 is not a valid bitstream:

$ MP4Box -add test.h264 test.mp4
Cannot find H264 start code
Error importing test.h264: BitStream Not Compliant

$ dd if=test.h264 of=headless-test.h264 bs=16136 skip=1
entrati 36+1 record
usciti 36+1 record

$ MP4Box -add headless-test.h264 test.mp4
AVC-H264 import - frame size 320 x 180 at 25.000 FPS
Import results: 346 samples - Slices: 14 I 318 P 0 B - 346 SEI - 14 IDR
Saving to test.mp4: 0.500 secs Interleaving

h264visa
22nd October 2007, 16:31
Hi fsinapsi,

Yes, it is. in fact, test.h264 is a H.264 byte stream(annex B).
Any way, I am very interest in your command sequence, what is the meaning of:

> $ dd if=test.h264 of=headless-test.h264 bs=16136 skip=1
> entrati 36+1 record
> usciti 36+1 record

Thanks.

h264visa
22nd October 2007, 16:37
Hi fsinapsi,

Another info:
> $ MP4Box -add headless-test.h264 test.mp4
> AVC-H264 import - frame size 320 x 180 at 25.000 FPS

this message is not correct, the frame size is 320 x 192, the frame rate is 15fps, which is in the SEI info.

You can verify the picture size by saving the output into a yuv file using H264visa.exe, and then play the yuv file using YuvVisa.exe(in the same H264Visa.zip package).

fsinapsi
22nd October 2007, 16:59
Any way, I am very interest in your command sequence, what is the meaning of:
> $ dd if=test.h264 of=headless-test.h264 bs=16136 skip=1
it removes 16136 bytes from the head of the file
Another info:
> $ MP4Box -add headless-test.h264 test.mp4
> AVC-H264 import - frame size 320 x 180 at 25.000 FPS
MP4Box assumes 25 fps, while MPlayer assumes 29.97 :)
Both programs are wrong...

$ mplayer test.h264
MPlayer dev-SVN-r24679-3.2 (C) 2000-2007 MPlayer Team
[...]
Playing test.h264.
H264-ES file format detected.
FPS seems to be: 29.970030
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 320 x 180 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 320x180 => 320x180 Planar YV12

this is very strange...
Why does MPlayer state the clip resolution is 320x180?
MP4Box states the same.
You can verify the picture size by saving the output into a yuv file using H264visa.exe,
I have not Windows... Is the source code available?
Thanks

fsinapsi
22nd October 2007, 20:55
Yes, it is. in fact, test.h264 is a H.264 byte stream(annex B).
I have compiled a version of the reference software ("jm"), and here is the output of "ldecod" ("ldecod" is the reference parser/decoder of H.264 bytestream in file format Annex B):


----------------------------- JM 12.2 (FRExt) -----------------------------
Decoder config file : (null)
--------------------------------------------------------------------------
Input H.264 bitstream : test.h264
Output decoded YUV : test_dec.yuv
Output status file : log.dec
Input reference file : test_rec.yuv does not exist
SNR values are not available
--------------------------------------------------------------------------
POC must = frame# or field# for SNRs to be correct
--------------------------------------------------------------------------
Frame POC Pic# QP SnrY SnrU SnrV Y:U:V Time(ms)
--------------------------------------------------------------------------
GetAnnexbNALU: no Start Code at the begin of the NALU, return -1
Error while getting the NALU in file format Annex B, exit
Found NALU type 0, len 0 undefined, ignore NALU, moving on
GetAnnexbNALU: no Start Code at the begin of the NALU, return -1
Error while getting the NALU in file format Annex B, exit
Found NALU type 0, len 0 undefined, ignore NALU, moving on
GetAnnexbNALU: no Start Code at the begin of the NALU, return -1
[...]
read_new_slice: Found NALU_TYPE_SEI, len 6
Warning: no active SPS, timing SEI cannot be parsed
read_new_slice: Found NALU_TYPE_SEI, len 6
Warning: no active SPS, timing SEI cannot be parsed
read_new_slice: Found NALU_TYPE_SEI, len 6
Warning: no active SPS, timing SEI cannot be parsed
[...]
0000(I) 0 0 22 0.0000 0.0000 0.0000 4:2:0 63
read_new_slice: Found NALU_TYPE_SEI, len 6
0000(P) 2 1 25 0.0000 0.0000 0.0000 4:2:0 16
read_new_slice: Found NALU_TYPE_SEI, len 6
0000(P) 4 2 23 0.0000 0.0000 0.0000 4:2:0 20
read_new_slice: Found NALU_TYPE_SEI, len 6
[...]
0000(P) 32 16 19 0.0000 0.0000 0.0000 4:2:0 47
read_new_slice: Found NALU_TYPE_SEI, len 6
0000(P) 34 17 18 0.0000 0.0000 0.0000 4:2:0 54
read_new_slice: Found NALU_TYPE_SEI, len 6
0000(P) 36 18 18 0.0000 0.0000 0.0000 4:2:0 50
ERROR: failed to find NumCoeff/TrailingOnes


Is that a too much old version of "jm" (12.2)?

Edit:
I have compiled a newer version of JM (12.4), but its output is the same as above.
You can download it from this page: http://iphome.hhi.de/suehring/tml/
I think a bitstream should begin with a startcode.
Anyway, MPlayer doesn't complain about that. It can play the sample with no problems; maybe it skips the parts it doesn't understand...

h264visa
23rd October 2007, 01:07
I think I have to port my tool into Linux.


this is very strange...
Why does MPlayer state the clip resolution is 320x180?
MP4Box states the same.

I know the answer now: From h264visa's analysis for SPS, I got
the following info:
frame_crop_bottom_offset = 6.
frame_crop_top_offset = 0
from the spec, it says:
vertical frame coordinates from
CropUnitY * frame_crop_top_offset to ( 16 * FrameHeightInMbs ) – ( CropUnitY * frame_crop_bottom_offset + 1 ), inclusive.


Here CropUnitY is 2 because the chroma format is 4:2:0. FrameHeightInMbs is pic_height_in_map_units_minus1 + 1, that is 12(12 x 16 = 192). so the vertical cooridinate is:
16 * 12 - (2 * 6 + 1), that is 179.
that means the vertical length is 180 -- Got it :).

For MP4Box, it should continue searching for the starting code after it fails to find it at the beginning, MPlayer is doing in this way, and H264visa does too.

h264visa
26th October 2007, 07:24
More feature added:
- mb bit numbers/qp/pqc overlay display on video.
- YuvVisa(YUV file playback and compare) is added
- Changed stage display control into a tab, more user-friendly.

Please check the homepage for H264Visa:
http://h264visa.daydayup.info

foxyshadis
26th October 2007, 09:07
It actually works extremely well for non-baseline video as well. So far it has no problem analyzing high profile video, though it tends to crash a lot more after a few play/pauses.

One issue I notice is that when a video is larger than the interface, it takes up the entire area instead of being confined to a space with scrollbars. Only really an issue with 1080p video. Also, would it be possible to make it autodetect mp4 and ts via the extension?

Great tool, very handy!

h264visa
26th October 2007, 18:38
It actually works extremely well for non-baseline video as well. So far it has no problem analyzing high profile video, though it tends to crash a lot more after a few play/pauses.
Thanks. I am very glad at that it can even work on high profile.

One issue I notice is that when a video is larger than the interface, it takes up the entire area instead of being confined to a space with scrollbars. Only really an issue with 1080p video.
Yes, this is a serious problem on big-size frames, I will fix it.

Also, would it be possible to make it autodetect mp4 and ts via the extension?
Good idea, I will add this feature.