Detect that the H.264 header is standard compliant?

[Sami32]

For example it seem that bad encoder or weird user setting set some SD H.264 with a reference frames of 9 to an artificial level 5.1 when in fact they are 4.1.

[Sami32]

For example tsMuxeR can change the H.264 level in the header on the fly.

[JeromeMartinez]

No test or modification, just reporting. Could be integrated but not on free support (so would be more expensive than just using tsMuxeR).

[Sami32]

It seem that you've misunderstood me ;)

Can MI report, detect that the AVC video level has been "artificially" alterated?

I know that crossing informations like bitrate and some others ones could detect that the level set into the media header is not conform, but i'm wondering if MI have already such option that i'm not aware of.

[JeromeMartinez]

I think I well understood ;-) "No test" part in my sentence, i.e. no detect that the AVC video level is not the right one ("altered" or "initially wrong", technically impossible to know). It is just read out of the value in the bistream.

I know that crossing informations like bitrate and some others ones could detect that the level set into the media header is not conform,

True; not a technical issue, just that it is not (yet) implemented.

[Sami32]

Sorry, your reference to modification and tsMuxer confused me, as i'm not aware that tsMuxeR is able to display such information. AFAIK it can only modify the header to compensate the wrong doing or practice done on AVC media.

Ok. Should i close this "issue" then? or did you said that a such implementaion will depend on sponsorship?

[JeromeMartinez]

your reference to modification and tsMuxer confused me

Got it, I misunderstood this part, it can change it (easy) but not compute it (so you need to manually provide info), if I understood better now.

or did you said that a such implementaion will depend on sponsorship?

Right.

[Sami32]

Yes, my interest was to have a MI field saying "Wrong level", that will make me aware that the level will have to be corrected on the fly to a compliant one.

[Nadahar]

Couldn't we detect that ourselves based on the other parsed information? It would probably be a big job to do for all codecs though, but only H.264 might not be so bad..? Or, are we missing some critical information to make the determination?

[Sami32]

AFAIK, only H.264 is affected by such bad practice. The necessary informations are in the standard but my knowledge on that is poor. The video resolution, bitrate, reference frames and probably some more informations are need.

[JeromeMartinez]

Couldn't we detect that ourselves based on the other parsed information?

If it is quick, I would have implemented it as I owe you lot of reports and fixes. It is not quick and current info not enough.

Or, are we missing some critical information to make the determination?

The part of the spec for profiles and levels is 20 pages long, with stuff like "Vertical MV component range" values and "PicWidthInMbs * FrameHeightInMbs <= MaxFS, where MaxFS is specified in Table A-1" checks to do, not speaking about the count of reference frames to check for each frame (anotehr part of the spec).

We have the skills for developing an open source AVC (or HEVC) conformance checker, but it is not doable in 1 day, at least for us.

[Sami32]

Oh yeah...i remember some of this chinese things seen on the way, and i admit that i get confused and didn't knew how to get these macroblocks informations. It is why i finally posted my question here ;-)