Recherche avancée

Sur d’autres sites (2836)

• What’s So Hard About Building ?

  10 septembre 2011, par Multimedia Mike — Programming

  I finally had a revelation as to why so building software can be so difficult– because build systems are typically built on programming languages that you don’t normally use in your day to day programming activities. If the project is simple enough, the build system usually takes care of the complexities. If there are subtle complexities — and there always are — then you can to figure out how to customize the build system to meet your needs.

  First, there’s the Makefile. It’s easy to forget that the syntax which comprises a Makefile pretty well qualifies as a programming language. I wonder if it’s Turing-complete ? But writing and maintaining Makefiles manually is arduous and many systems have been created to generate Makefiles for you. At the end of the day, running ‘make’ still requires the presence of a Makefile and in the worst case scenario, you’re going to have to inspect and debug what was automatically generated for that Makefile.

  So there is the widespread GNU build system, a.k.a., “the autotools”, named due to its principle components such as autoconf and automake. In this situation, you have no fewer than 3 distinct languages at work. You write your general build instructions using a set of m4 macros (language #1). These get processed by the autotools in order to generate a shell script (language #2) called configure. When this is executed by the user, it eventually generates a Makefile (language #3).

  Over the years, a few challengers have attempted to dethrone autotools. One is CMake which configures a project using its own custom programming language that you will need to learn. Configuration generates a standard Makefile. So there are 2 languages involved in this approach.

  Another option is SCons, which is Python-based, top to bottom. Only one programming language is involved in the build system ; there’s no Makefile generated and run. Until I started writing this, I was guessing that the Python component generated a Makefile, but no.

  That actually makes SCons look fairly desirable, at least if your only metric when choosing a build system is to minimize friction against rarely-used programming languages.

  I should also make mention of a few others : Apache Ant is a build system in which the build process is described by an XML file. XML doesn’t qualify as a programming language (though that apparently doesn’t stop some people from using it as such). I see there’s also qmake, related to the Qt system. This system uses its own custom syntax.

• fate/cbs : simplify the filter_unit discard tests

  30 juin 2023, par James Almer

  fate/cbs : simplify the filter_unit discard tests
  No need to generate intermediate files and probe them. We only care to know that the
  
  output of the bsf excludes the frames in question, and a simple checksum is enough.
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] tests/fate/cbs.mak
  • [DH] tests/ref/fate/cbs-h264-discard-bidir
  • [DH] tests/ref/fate/cbs-h264-discard-nonintra
  • [DH] tests/ref/fate/cbs-h264-discard-nonkey
  • [DH] tests/ref/fate/cbs-h264-discard-nonref
  • [DH] tests/ref/fate/cbs-hevc-discard-bidir
  • [DH] tests/ref/fate/cbs-hevc-discard-nonintra
  • [DH] tests/ref/fate/cbs-hevc-discard-nonkey
  • [DH] tests/ref/fate/cbs-hevc-discard-nonref

• How do I extract color matrix from MP4 an x264 stream in Media Foundation

  23 août 2016, par Jules

  I am playing a video (mp4 containing x264 encoded video stream) with a custom player using media foundation.

  When I convert the YUV information into RGB I need to account for the color matrix and range used at encode time.

  Some of my videos have this information, I can use MediaInfo.exe or FFMPEG to see that it is present.

  However, for such videos if I look at the relevant Media Foundation properties (Extended Color Information) the properties are not present in the files.

  So, somehow I need to find a way to access the information.

  Media Foundation does provide access to MF_MT_MPEG4_SAMPLE_DESCRIPTION and MF_MT_MPEG_SEQUENCE_HEADER for the video stream but I can’t find descriptions of what these contain.

  I noticed that the MF_MT_MPEG_SEQUENCE_HEADER is much longer for the videos with the information present and this (MPEG Headers Quick Reference) seems to suggest headers might contain the information I need.

  I’m looking for Color Range (limited/full), Color Primaries, Transfer Characteristics and Matrix Coefficients (BT.709 etc).

  I’d greatly appreciate any help finding this information from a Media Foundation video stream.

  Thanks

  Jules

  ---

  Update - Sequence Header

  The sequence header appears to be a subset of MPEG4 sample description, though I can’t find anything that indicates what either bits of data actually contains / doesn’t contain specifically.

  The sequence header appears to contain data structured as an MP4 byte stream as described in the H264 Standards Document and includes the VUI (Video Usability Information - Annex E of document) which may then include the colour information I’m interested in.

  Given that it’s a byte stream I need to know where it starts and whether there’s some existing code I could use to decode it.

  In FFMPEG in libavcodec/h264_ps.c there is a function called ff_h264_decode_seq_parameter_set which ends up calling decode_vui_parameters. It seems possible that seq_parameter_set maps to MF_MT_MPEG_SEQUENCE_HEADER and it may be possible to use that code to decode the data.

  If anyone one has any direct experience with decoding this data it would be very useful.

  Thanks again

  ---

  Update - Related posts

  I found this How to decode sprop-parameter-sets in a H264 SDP ? and Possible Locations for Sequence/Picture Parameter Set(s) for H.264 Stream which are fairly helpful.

  The sequence header would appear to be Sequence or picture parameter set (pps) and the parameters I want are the VUI extension subset.

  Plus this post H.264 stream structure gives the high level of how the stream data is structured, and the MF_MT_MPEG_SEQUENCE_HEADER appears to start with a NAL 0x00 0x00 0x01 so I’m guessing it is a NAL containing the PPS.