Bug 83689 - [PATCH] mjpegtools: 1) libpng problem and 2) FreeBSD 4 mplex problem
Summary: [PATCH] mjpegtools: 1) libpng problem and 2) FreeBSD 4 mplex problem
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Michael Johnson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-18 21:10 UTC by Sven Berkvens-Matthijsse
Modified: 2005-07-20 09:17 UTC (History)
0 users

See Also:


Attachments
file.diff (3.22 KB, patch)
2005-07-18 21:10 UTC, Sven Berkvens-Matthijsse
no flags Details | Diff
file.diff (436 bytes, patch)
2005-07-18 21:10 UTC, Sven Berkvens-Matthijsse
no flags Details | Diff
file.diff (1.09 KB, patch)
2005-07-18 21:10 UTC, Sven Berkvens-Matthijsse
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Berkvens-Matthijsse 2005-07-18 21:10:07 UTC
	There are two problems with this ports on my FreeBSD 4.10 system.
	The first of the two probably also applies to FreeBSD 5.x.

	First problem: libpng is not detected by mjpegtools' configure. This
	is because pkg-config is asked to check for a package named "libpng",
	but on my FreeBSD 4.10 system, the png port installs itself as a
	pkg-config "libpng12" package, and thus, the mjpegtools does not
	compile the png2yuv package, which I need :-) I have contacted the
	mjpegtools developer at Sourceforge regarding this problem, so it
	could be that they will fix the problem themselves. In the meantime,
	the patch provided below will fix the problem.

	Second problem: this only applies to FreeBSD 4.x because FreeBSD 5.x
	uses another threading library by default. The problem with the
	FreeBSD 4.x threading library is that it is a simulation of threads.
	This means, amongst other things, that all file descriptors that are
	open when a threaded program is started, are changed to non-blocking
	mode. In itself, this is no problem. But here's the catch: if I tell
	mplex to write its results to /dev/stdout, mplex will open /dev/stdout.
	Internally in the kernel, this will just clone file descriptor 1,
	which is already set to non-blocking mode! Now, the threading library
	checks which flags the newly opened file has and adapts its behaviour
	accordingly. This means that the newly opened file is non-blocking in
	the userland thread as well! Now when mplex writes to dvdauthor, for
	example, and mplex is faster than dvdauthor, it will get short writes
	and abort. This is obviously unwanted behaviour. I realize that the
	real problem lies in the way in which threads work in FreeBSD 4.x, but
	there is no chance of things being fixed on that side. The patch
	provided should not interfere with FreeBSD 5.x, by the way. It simply
	sets all opened file descriptors to blocking mode (at least, the
	threading library's behaviour).

Fix: First problem's patch:

	/usr/ports/multimedia/mjpegtools/files/patch-configure

-----8<------8<------8<-----
-----8<------8<------8<----- 

	Also for the first problem:
	/usr/ports/multimedia/mjpegtools/files/patch-configure.ac

-----8<------8<------8<----- 
-----8<------8<------8<-----


	For the second problem:
	/usr/ports/multimedia/mjpegtools/files/patch-mplex::main.cpp

-----8<------8<------8<-----
How-To-Repeat: 	First problem: try installing this port and then running png2yuv.

	Second problem: only applicable on FreeBSD 4.x. Run mplex with
	/dev/stdout as the output file and make mplex's stdout something
	slow, like piping it through sleep 60 :-)
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2005-07-19 09:55:36 UTC
Responsible Changed
From-To: freebsd-ports-bugs->ahze

Over to maintainer.
Comment 2 Michael Johnson freebsd_committer freebsd_triage 2005-07-20 09:14:45 UTC
State Changed
From-To: open->closed

Committed, Thanks!