Welcome Guest ( Log In | Register )


Important

The forums will be closing permanently the weekend of March 15th. Please see the notice in the announcements forum for details.

 
B-frame Coloring In The Status/video Histogram
« Next Oldest | Next Newest » Track this topic | Email this topic | Print this topic
Sarreq Teryx
Posted: Mar 9 2003, 10:47 AM


VirtualdubMod Alpha tester


Group: Vdubmod Alpha Testing Team
Posts: 175
Member No.: 41
Joined: 16-July 02



very minor, but is it possible for virtualdub(mod) to make b-frames another color in the compression histogram? or is that a vfw issue that they're colored the same as p-frames?

--------------------
And as I walk through the Valley of the Shadow of Death, Lord, thy balls and shaft, they comfort me, you annoint my head with oil, some salt, a dash of pepper, a sprigg of parsley......Lord?............Lord??? What dost thou intend to do with that fork???
 
    Top
ChristianHJW
Posted: Mar 9 2003, 12:01 PM


Advanced Member


Group: Moderators
Posts: 1768
Member No.: 2
Joined: 7-July 02



AVI container, as well as OGM, dont have any flags marking B frames. Again, matroska in its 'native' MPEG4 mode ( and only then, not in VFW/AVI compatibility ) will allow this feature ....

--------------------
Visit the unofficial Virtualdub support forum on http://forums.virtualdub.org - help to reduce the big number of emails Avery Lee is getting every day !!
Support matroska as container and Gstreamer as the only truely open, x-platform multimedia platform ....
 
       Top
Sarreq Teryx
Posted: Mar 9 2003, 04:27 PM


VirtualdubMod Alpha tester


Group: Vdubmod Alpha Testing Team
Posts: 175
Member No.: 41
Joined: 16-July 02



but while encoding, should that matter. wouldn't it be able to tell the difference before stuffing it into the avi/ogm?

--------------------
And as I walk through the Valley of the Shadow of Death, Lord, thy balls and shaft, they comfort me, you annoint my head with oil, some salt, a dash of pepper, a sprigg of parsley......Lord?............Lord??? What dost thou intend to do with that fork???
 
    Top
muf
Posted: Mar 9 2003, 09:08 PM


MCF team member


Group: Moderators
Posts: 179
Member No.: 46
Joined: 21-July 02



QUOTE (Sarreq Teryx @ Mar 9 2003, 10:27 AM)
but while encoding, should that matter. wouldn't it be able to tell the difference before stuffing it into the avi/ogm?

Maybe implement some debugview functions ? You might be able to get codec-specific data like quantizers even, for xvid & divx4/5.

--------------------
user posted image
 
     Top
phaeron
Posted: Mar 10 2003, 03:59 AM


Virtualdub Developer


Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02



QUOTE

but while encoding, should that matter. wouldn't it be able to tell the difference before stuffing it into the avi/ogm?


The Windows Video Compression Manager (VCM) interface doesn't have a notion of B-frames, and neither does AVI. For that matter, I don't think DirectShow does either (only sync marks). Client applications don't care as long as the matching decoder can tell from the compressed data what frame type is used. The client can also check the compressed data directly to discover this information, but this violates the "black box" codec paradigm and requires special case code per format supported.

As a side note, having such special case code makes "fast rekey" possible -- being able to rederive the keyframe flags without having to decompress any of the data. That would speed up rekey speed from one-half decode rate to the speed of the hard disk.

QUOTE

Maybe implement some debugview functions ? You might be able to get codec-specific data like quantizers even, for xvid & divx4/5.


I hope you're not talking about Win32 debug output. There are known deadlock issues with OutputDebugString() and synchronization objects under Windows NT platforms that make it inadvisable for data exchange. Polluting the debug channel for this will also royally piss off anyone who is using a debugger.
 
    Top
muf
Posted: Mar 10 2003, 11:37 AM


MCF team member


Group: Moderators
Posts: 179
Member No.: 46
Joined: 21-July 02



QUOTE (phaeron @ Mar 9 2003, 09:59 PM)
I hope you're not talking about Win32 debug output. There are known deadlock issues with OutputDebugString() and synchronization objects under Windows NT platforms that make it inadvisable for data exchange. Polluting the debug channel for this will also royally piss off anyone who is using a debugger.

Don't know really, I've never worked with debugview. It seems to be able to get codec data while encoding, and is used to gather statistics after a pass.

--------------------
user posted image
 
     Top
Sarreq Teryx
Posted: Mar 10 2003, 08:51 PM


VirtualdubMod Alpha tester


Group: Vdubmod Alpha Testing Team
Posts: 175
Member No.: 41
Joined: 16-July 02



QUOTE (phaeron @ Mar 9 2003, 10:59 PM)
QUOTE

but while encoding, should that matter. wouldn't it be able to tell the difference before stuffing it into the avi/ogm?


The Windows Video Compression Manager (VCM) interface doesn't have a notion of B-frames, and neither does AVI. For that matter, I don't think DirectShow does either (only sync marks). Client applications don't care as long as the matching decoder can tell from the compressed data what frame type is used. The client can also check the compressed data directly to discover this information, but this violates the "black box" codec paradigm and requires special case code per format supported.

As a side note, having such special case code makes "fast rekey" possible -- being able to rederive the keyframe flags without having to decompress any of the data. That would speed up rekey speed from one-half decode rate to the speed of the hard disk.

so, that's an "it could be done, but would require mad amounts of extra programming per codec supported"? or did I read that wrong?

what's the black box codec pardigm exactly?

--------------------
And as I walk through the Valley of the Shadow of Death, Lord, thy balls and shaft, they comfort me, you annoint my head with oil, some salt, a dash of pepper, a sprigg of parsley......Lord?............Lord??? What dost thou intend to do with that fork???
 
    Top
phaeron
Posted: Mar 11 2003, 03:22 AM


Virtualdub Developer


Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02



QUOTE

so, that's an "it could be done, but would require mad amounts of extra programming per codec supported"? or did I read that wrong?


Yup. Essentially, what's required is code to detect that DivX/XviD/whatever is in use, and then special code for that format to pick out the frame type.

QUOTE

what's the black box codec pardigm exactly?


"Black box" means you have a box that does X, but you don't know or care how it does X. In this case, Win32 codecs are designed so that an application can compress or decompress video without any knowledge of the compressed format -- compressed video is passed verbatim in and out of the codec as an opaque, unknown format by the application. The idea is that as long as a codec can be written to conform to the Video for Windows API, any application that uses that API can use that codec and its accompanying format, regardless of what kind of compression algorithm is used. When applications have to check for specific formats and go spelunking into the compressed frames, you lose generality, as now every application has to be retrofitted to support each new format that requires such spelunking.
 
    Top
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:
7 replies since Mar 9 2003, 10:47 AM Track this topic | Email this topic | Print this topic

<< Back to VirtualDub Development Forum