Fix for bug on flowplayer script

[mythtv@…]

The file stream_flv.pl in mythweb/modules/stream is responsible for on the fly transcoding to flv format, when using the flowplayer in MythWeb For some reason ffmpeg is only able to transcode to a size with even height and width. When calculating the screen size of the file to stream based on the size of the existing recording, the script attempts to use the function round_even in Math::Round to round to an even number. Unfortunately this function only rounds to an even number when rounding a decimal number, but in some cases, the value passed to round_even is an odd number without decimals. This causes ffmpeg to be launched with an odd target size, and ultimately fail.

The 3 calls to round_even in the script need to be replaced with calls to nearest_floor(2, Which is part of the same Math::Round package. This will make sure to spit out only even integers and nothing else.

Attached is the modified script file. Please include this fix into the source code.

[anonymous]

Patched files

[robertm]

Please attach a unified diff (diff -u or svn diff) rather than a raw file.

[anonymous]

Diff

[xris]

Dupe of #8469.

Additionally, the patch doesn't apply cleanly against current trunk. Please reopen if this is still an issue in trunk, but I suspect that it was resolved in [24931].

[javamatte@…]

The query is still wrong (at least for my system) in the stream_flv.pl script.

It gets the width/height using this query: $sh = $dbh->prepare('SELECT data FROM recordedmarkup WHERE chanid=? AND starttime=FROM_UNIXTIME(?) AND data IS NOT NULL ORDER BY data DESC');

In my database, there is another datum added that might be the number of frames (type = 32) and is usually in the tens of thousands. So the width is set to 29000 and then the aspect ratio is calculated incorrectly.

Changing the query to this: $sh = $dbh->prepare('SELECT data FROM recordedmarkup WHERE chanid=? AND starttime=FROM_UNIXTIME(?) AND data IS NOT NULL ORDER BY type');

sorts type = 30 first (this contains width in my DB), 31 second (this contains height) and then 32 (whatever the absurdly large number is).

I don't have the setup to provide a patch, but this is the only ref I found when googling the problem (squished video in mythweb streaming), so I figured I would post it here in case anyone was paying attention.

[beirdo]

I will take a look at this revised bug. The query shown does seem absurd to me, shouldn't be hard to fix.

[justin.johnson3@…]

I've been using this query to ignore the other type:

$dbh->prepare('SELECT data FROM recordedmarkup WHERE chanid=? AND starttime=FROM_UNIXTIME(?) AND mark<10 AND (TYPE=30 OR TYPE=31) AND data IS NOT NULL ORDER BY data DESC');

This grabs the initial size (I had an issue where the size would change on ads).

[beirdo]

(In [27067]) Makes stream_flv.pl pull the width and height from the database correctly. Now only asks for the width and height, and doesn't assume that they are the largest two non-null marks.

Fixes #9036

[beirdo]

(In [27068]) Merged 27067 from trunk.

Makes stream_flv.pl pull the width and height from the database correctly. Now only asks for the width and height, and doesn't assume that they are the largest two non-null marks.

Fixes #9036

[octoberblu3@…]

This patch works properly when the video records cleanly, but when I get digital artifacts on my DTA, the analog recording has many entries for types 30 and 31. Here is a search on one such program:

chanid	starttime	mark	type	data
2041	2010-11-10 22:59:00	0	30	720
2041	2010-11-10 22:59:00	34461	30	2796
2041	2010-11-10 22:59:00	34464	30	720
2041	2010-11-10 22:59:00	36156	30	4094
2041	2010-11-10 22:59:00	36160	30	720
2041	2010-11-10 22:59:00	64478	30	6
2041	2010-11-10 22:59:00	64480	30	720
2041	2010-11-10 22:59:00	76205	30	3748
2041	2010-11-10 22:59:00	76210	30	720
2041	2010-11-10 22:59:00	0	31	480
2041	2010-11-10 22:59:00	34461	31	3840
2041	2010-11-10 22:59:00	34464	31	480
2041	2010-11-10 22:59:00	36156	31	98
2041	2010-11-10 22:59:00	36160	31	480
2041	2010-11-10 22:59:00	64478	31	3922
2041	2010-11-10 22:59:00	64480	31	480
2041	2010-11-10 22:59:00	76205	31	3568
2041	2010-11-10 22:59:00	76210	31	480
2041	2010-11-10 22:59:00	0	32	29970

Since this patch just takes the first two entries for the width and height, the aspect ratio is horribly off in Flowplayer (720x2796 scaled down).

Just adding in 'AND mark=0' in the query fixes this on my system.

[beirdo]

(In [27173]) Fix the case where the detected resolution is all over the place. Make the FLV player scale based on only the initial resolution at frame 0.

Fixes #9036.

[beirdo]

(In [27174]) Backport [27173] from trunk

Fix the case where the detected resolution is all over the place. Make the FLV player scale based on only the initial resolution at frame 0.

Fixes #9036.