Mailing List Archive: MythTV: Dev

Found a severe decoding bug in mythffplay

Index | Next | Previous | View Threaded

mark at mrobinson

May 3, 2012, 8:39 PM

Post #1 of 24 (889 views)
Permalink

Found a severe decoding bug in mythffplay

Hey Guys,

I just upgraded to MythTV-0.25-fixes and I've found a rather serious
decoding bug.

If you use mythffplay to play a video file then the blue and red color
channels will be reversed.

If I play the video on a different machine, it works fine.
If I play the video using Xine or mplayer on the same machine, it works
fine.

Only mythffplay causes problems.

Let me know if you would like me to provide more information.

Mark

Software:
Ubuntu 12.04
$> mythffplay -version
FFplay version UNKNOWN, Copyright (c) 2003-2011 the FFmpeg developers
built on Apr 10 2012 09:34:56 with gcc 4.6.3
configuration: --compile-type=profile --prefix=/usr --runprefix=/usr
--enable-crystalhd --enable-lirc --enable-audio-alsa --enable-audio-oss
--enable-dvb --enable-ivtv --enable-firewire --enable-joystick-menu
--with-bindings=perl --enable-ffmpeg-pthreads --enable-pic --enable-vaapi
--perl-config-opts='INSTALLDIRS=vendor' --enable-libvpx --enable-libx264
--enable-libmp3lame --enable-libfaac --enable-libxvid --enable-nonfree
--enable-opengl-video --cpu=i686 --enable-mmx --enable-vdpau
libavutil 50. 39. 0 / 50. 39. 0
libavcodec 52.113. 1 / 52.113. 1
libavformat 52.101. 0 / 52.101. 0
libavdevice 52. 2. 3 / 52. 2. 3
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 12. 0 / 0. 12. 0
libpostproc 51. 2. 0 / 51. 2. 0
FFplay UNKNOWN
libavutil 50. 39. 0 / 50. 39. 0
libavcodec 52.113. 1 / 52.113. 1
libavformat 52.101. 0 / 52.101. 0
libavdevice 52. 2. 3 / 52. 2. 3
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 12. 0 / 0. 12. 0
libpostproc 51. 2. 0 / 51. 2. 0

$> lspci -vv
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Manhattan [Mobility Radeon HD 5430 Series] (prog-if 00 [VGA controller])
Subsystem: Hightech Information System Ltd. Device 3000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 44
Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at e6000000 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at c000 [size=256]
[virtual] Expansion ROM at e5000000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: radeon
Kernel modules: radeon

raymond at wagnerrp

May 3, 2012, 9:41 PM

Post #2 of 24 (878 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 5/3/2012 23:39, Mark Robinson wrote:
> I just upgraded to MythTV-0.25-fixes and I've found a rather serious
> decoding bug.
>
> If you use mythffplay to play a video file then the blue and red color
> channels will be reversed.
>
> If I play the video on a different machine, it works fine.
> If I play the video using Xine or mplayer on the same machine, it
> works fine.
>
> Only mythffplay causes problems.

If `mythffplay` doesn't work, the best option would be to disable it, or
just simply not use it. MythTV's diagnostic playback tool is
`mythavtest`. We added `mythffmpeg` to give a static copy of the ffmpeg
transcoding utility for scripts to use, built off MythTV's internal
snapshot of the ffmpeg libraries. `mythffplay` gets compiled for no
reason other than we could.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mark at mrobinson

May 4, 2012, 12:23 PM

Post #3 of 24 (864 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

I've tried mythavtest. It also swaps the color channels.

Mark

On Thu, May 3, 2012 at 9:41 PM, Raymond Wagner <raymond [at] wagnerrp> wrote:

> On 5/3/2012 23:39, Mark Robinson wrote:
>
>> I just upgraded to MythTV-0.25-fixes and I've found a rather serious
>> decoding bug.
>>
>> If you use mythffplay to play a video file then the blue and red color
>> channels will be reversed.
>>
>> If I play the video on a different machine, it works fine.
>> If I play the video using Xine or mplayer on the same machine, it works
>> fine.
>>
>> Only mythffplay causes problems.
>>
>
> If `mythffplay` doesn't work, the best option would be to disable it, or
> just simply not use it. MythTV's diagnostic playback tool is `mythavtest`.
> We added `mythffmpeg` to give a static copy of the ffmpeg transcoding
> utility for scripts to use, built off MythTV's internal snapshot of the
> ffmpeg libraries. `mythffplay` gets compiled for no reason other than we
> could.
> ______________________________**_________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/**listinfo/mythtv-dev<http://www.mythtv.org/mailman/listinfo/mythtv-dev>
>

mtdean at thirdcontact

May 4, 2012, 12:44 PM

Post #4 of 24 (864 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 05/04/2012 03:23 PM, Mark Robinson wrote:
> On Thu, May 3, 2012 at 9:41 PM, Raymond Wagner wrote:
>> On 5/3/2012 23:39, Mark Robinson wrote:
>>> I just upgraded to MythTV-0.25-fixes and I've found a rather serious
>>> decoding bug.
>>>
>>> If you use mythffplay to play a video file then the blue and red color
>>> channels will be reversed.
>>>
>>> If I play the video on a different machine, it works fine.
>>> If I play the video using Xine or mplayer on the same machine, it works
>>> fine.
>>>
>>> Only mythffplay causes problems.
>> If `mythffplay` doesn't work, the best option would be to disable it, or
>> just simply not use it. MythTV's diagnostic playback tool is `mythavtest`.
>> We added `mythffmpeg` to give a static copy of the ffmpeg transcoding
>> utility for scripts to use, built off MythTV's internal snapshot of the
>> ffmpeg libraries. `mythffplay` gets compiled for no reason other than we
>> could.
> I've tried mythavtest. It also swaps the color channels.
>

Are you using a version of MythTV after Apr 13 (either 0.25-fixes or
unstable/development/master)?

https://github.com/MythTV/mythtv/commit/0f8476995

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mark at mrobinson

May 4, 2012, 1:07 PM

Post #5 of 24 (864 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

I'm using 0.25-fixes.

So I managed to 'solve' the problem by setting the video output driver to
be OpenGL rather than Xv. However, if I use mplayer or xine and force them
to use the Xv output they work fine.

Mark

On Fri, May 4, 2012 at 12:44 PM, Michael T. Dean <mtdean [at] thirdcontact>wrote:

> On 05/04/2012 03:23 PM, Mark Robinson wrote:
>
>> On Thu, May 3, 2012 at 9:41 PM, Raymond Wagner wrote:
>>
>>> On 5/3/2012 23:39, Mark Robinson wrote:
>>>
>>>> I just upgraded to MythTV-0.25-fixes and I've found a rather serious
>>>> decoding bug.
>>>>
>>>> If you use mythffplay to play a video file then the blue and red color
>>>> channels will be reversed.
>>>>
>>>> If I play the video on a different machine, it works fine.
>>>> If I play the video using Xine or mplayer on the same machine, it works
>>>> fine.
>>>>
>>>> Only mythffplay causes problems.
>>>>
>>> If `mythffplay` doesn't work, the best option would be to disable it, or
>>> just simply not use it. MythTV's diagnostic playback tool is
>>> `mythavtest`.
>>> We added `mythffmpeg` to give a static copy of the ffmpeg transcoding
>>> utility for scripts to use, built off MythTV's internal snapshot of the
>>> ffmpeg libraries. `mythffplay` gets compiled for no reason other than we
>>> could.
>>>
>> I've tried mythavtest. It also swaps the color channels.
>>
>>
> Are you using a version of MythTV after Apr 13 (either 0.25-fixes or
> unstable/development/master)?
>
> https://github.com/MythTV/**mythtv/commit/0f8476995<https://github.com/MythTV/mythtv/commit/0f8476995>
>
> Mike
>
> ______________________________**_________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/**listinfo/mythtv-dev<http://www.mythtv.org/mailman/listinfo/mythtv-dev>
>

mtdean at thirdcontact

May 4, 2012, 1:32 PM

Post #6 of 24 (862 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 05/04/2012 04:07 PM, Mark Robinson wrote:
> On Fri, May 4, 2012 at 12:44 PM, Michael T. Dean wrote:
>
>> On 05/04/2012 03:23 PM, Mark Robinson wrote:
>>
>>> On Thu, May 3, 2012 at 9:41 PM, Raymond Wagner wrote:
>>>
>>>> On 5/3/2012 23:39, Mark Robinson wrote:
>>>>
>>>>> I just upgraded to MythTV-0.25-fixes and I've found a rather serious
>>>>> decoding bug.
>>>>>
>>>>> If you use mythffplay to play a video file then the blue and red color
>>>>> channels will be reversed.
>>>>>
>>>>> If I play the video on a different machine, it works fine.
>>>>> If I play the video using Xine or mplayer on the same machine, it works
>>>>> fine.
>>>>>
>>>>> Only mythffplay causes problems.
>>>>>
>>>> If `mythffplay` doesn't work, the best option would be to disable it, or
>>>> just simply not use it. MythTV's diagnostic playback tool is
>>>> `mythavtest`.
>>>> We added `mythffmpeg` to give a static copy of the ffmpeg transcoding
>>>> utility for scripts to use, built off MythTV's internal snapshot of the
>>>> ffmpeg libraries. `mythffplay` gets compiled for no reason other than we
>>>> could.
>>>>
>>> I've tried mythavtest. It also swaps the color channels.
>>>
>>>
>> Are you using a version of MythTV after Apr 13 (either 0.25-fixes or
>> unstable/development/master)?
>>
>> https://github.com/MythTV/**mythtv/commit/0f8476995<https://github.com/MythTV/mythtv/commit/0f8476995>
> I'm using 0.25-fixes.

Yes, but which revision.

mythfrontend --version

> So I managed to 'solve' the problem by setting the video output driver to
> be OpenGL rather than Xv. However, if I use mplayer or xine and force them
> to use the Xv output they work fine.

If you're using a new enough revision of 0.25-fixes, please go into
playback with the Xv video renderer, and hit F (one or more times, as
required), then adjust the hue--likely to either 0 or 50.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

jyavenard at gmail

May 4, 2012, 2:38 PM

Post #7 of 24 (863 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 5 May 2012 06:32, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> If you're using a new enough revision of 0.25-fixes, please go into playback
> with the Xv video renderer, and hit F (one or more times, as required), then
> adjust the hue--likely to either 0 or 50.

This option/fix is valid for any versions of fixes/0.25, including the
first release.

What has changed since is the default hue value calculated for some
cards, in such that it shouldnt be required for most to adjust the hue
value
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

May 4, 2012, 3:11 PM

Post #8 of 24 (861 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 05/04/2012 05:38 PM, Jean-Yves Avenard wrote:
> On 5 May 2012 06:32, Michael T. Dean wrote:
>> If you're using a new enough revision of 0.25-fixes, please go into playback
>> with the Xv video renderer, and hit F (one or more times, as required), then
>> adjust the hue--likely to either 0 or 50.
> This option/fix is valid for any versions of fixes/0.25, including the
> first release.
>
> What has changed since is the default hue value calculated for some
> cards, in such that it shouldnt be required for most to adjust the hue
> value

Right, the "If you're using a new enough version..." part was more of a
"you should be using current -fixes so you'll get all of the bug fixes
that go in there suggestion.

But, as you said, the playback picture controls (F) work in any
version--the challenge in versions without the fix is finding the right
values for a given video card. (So, it's generally easiest to upgrade
to a revision with the fix. :)

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

knowledgejunkie at gmail

May 4, 2012, 5:40 PM

Post #9 of 24 (859 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 4 May 2012 23:11, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> On 05/04/2012 05:38 PM, Jean-Yves Avenard wrote:
>
>> On 5 May 2012 06:32, Michael T. Dean wrote:
>>>
>>> If you're using a new enough revision of 0.25-fixes, please go into
>>> playback
>>> with the Xv video renderer, and hit F (one or more times, as required),
>>> then
>>> adjust the hue--likely to either 0 or 50.
>>
>> This option/fix is valid for any versions of fixes/0.25, including the
>> first release.
>>
>> What has changed since is the default hue value calculated for some
>> cards, in such that it shouldnt be required for most to adjust the hue
>> value
>
>
> Right, the "If you're using a new enough version..." part was more of a "you
> should be using current -fixes so you'll get all of the bug fixes that go in
> there suggestion.

On a related note: are there any plans to upload nightly 0.2x-fixes
tarballs and make those available instead (or even in addition) of the
release/point release tarballs on the official website, for those
users who do not checkout from github or use pre-built binaries?

Cheers,
Nick

--
Nick Morrott

MythTV Official wiki: http://mythtv.org/wiki/
MythTV users list archive: http://www.gossamer-threads.com/lists/mythtv/users

"An investment in knowledge always pays the best interest." - Benjamin Franklin
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

jyavenard at gmail

May 4, 2012, 5:57 PM

Post #10 of 24 (862 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

Hi

On Saturday, 5 May 2012, Nick Morrott wrote:

> On 4 May 2012 23:11, Michael T. Dean
>
> On a related note: are there any plans to upload nightly 0.2x-fixes
> tarballs and make those available instead (or even in addition) of the
> release/point release tarballs on the official website, for those
> users who do not checkout from github or use pre-built binaries?
>
> Cheers,
> Nick
>

IMHO; that's what point release are for.

bc-mythtv at comcast

May 4, 2012, 6:15 PM

Post #11 of 24 (862 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On Saturday, 5 May 2012, Nick Morrott wrote:
>
> On a related note: are there any plans to upload nightly 0.2x-fixes
> tarballs and make those available instead (or even in addition) of the
> release/point release tarballs on the official website, for those
> users who do not checkout from github or use pre-built binaries?
>
> Cheers,
> Nick

You can always get the latest tarball at
https://github.com/MythTV/mythtv/tarball/fixes/0.25

Though I have to say that it seems a bit wasteful if you are doing it
frequently. Better just checkout from git.

Bolek
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

May 4, 2012, 10:42 PM

Post #12 of 24 (845 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 05/04/2012 08:57 PM, Jean-Yves Avenard wrote:
> Hi
>
> On Saturday, 5 May 2012, Nick Morrott wrote:
>> On 4 May 2012 23:11, Michael T. Dean
>>
>> On a related note: are there any plans to upload nightly 0.2x-fixes
>> tarballs and make those available instead (or even in addition) of the
>> release/point release tarballs on the official website, for those
>> users who do not checkout from github or use pre-built binaries?
> IMHO; that's what point release are for.

Yeah, I don't think it's worth doing nightly tarballs or anything.

Then again, I'd love to just remove the tarballs from our website and
let users/packagers either clone the repo with git or use github tarball
links. TTBOMK, this would actually work, now, since Stuart M modified
the version script to allow us to always keep a VERSION file in place,
such that it's only used on systems without git tools or where the
tarball contains a git export (rather than a repo).

With that approach--as long as we post the -fixes tarball link rather
than the release tag tarball link--users would still get the
most-current fixes.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

ctreleaven at cogeco

May 6, 2012, 12:59 PM

Post #13 of 24 (834 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

At 1:42 AM -0400 5/5/12, Michael T. Dean wrote:
>On 05/04/2012 08:57 PM, Jean-Yves Avenard wrote:
>>Hi
>>
>>On Saturday, 5 May 2012, Nick Morrott wrote:
>>>On 4 May 2012 23:11, Michael T. Dean
>>>
>>>On a related note: are there any plans to upload nightly 0.2x-fixes
>>>tarballs and make those available instead (or even in addition) of the
>>>release/point release tarballs on the official website, for those
>>>users who do not checkout from github or use pre-built binaries?
>>IMHO; that's what point release are for.
>
>Yeah, I don't think it's worth doing nightly tarballs or anything.
>
>Then again, I'd love to just remove the tarballs from our website
>and let users/packagers either clone the repo with git or use github
>tarball links. TTBOMK, this would actually work, now, since Stuart
>M modified the version script to allow us to always keep a VERSION
>file in place, such that it's only used on systems without git tools
>or where the tarball contains a git export (rather than a repo).
>
>With that approach--as long as we post the -fixes tarball link
>rather than the release tag tarball link--users would still get the
>most-current fixes.
>

Mike, I was looking at packaging Myth for OS X via MacPorts. The
folks there are strongly biased against pulling from version control
systems because:
-security. Verifying checksums on a tarball gives quite strong
assurance that no malicious changes have been introduced since the
packager looked at it.
-repeatability. More chance that the user's install will succeed and
function as intended.
-availability. Tarballs can be mirrored on their site to increase
availability (and a recent email from Stuart Morgan indicates this is
a non-trivial problem with GitHub).
-other stuff I can't remember now.

Those seem like reasonable constraints/objectives for many packagers.

Semi-frequent point releases would fit their model better. (Perhaps
every 2-3 weeks early in a release cycle and sliding to every month
or two as the release matures.)

Craig
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

raymond at wagnerrp

May 6, 2012, 1:19 PM

Post #14 of 24 (832 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 5/6/2012 15:59, Craig Treleaven wrote:
> At 1:42 AM -0400 5/5/12, Michael T. Dean wrote:
>> Yeah, I don't think it's worth doing nightly tarballs or anything.
>>
>> Then again, I'd love to just remove the tarballs from our website and
>> let users/packagers either clone the repo with git or use github
>> tarball links.
>>
>
> Mike, I was looking at packaging Myth for OS X via MacPorts. The folks
> there are strongly biased against pulling from version control systems
> because:
> -security. Verifying checksums on a tarball gives quite strong
> assurance that no malicious changes have been introduced since the
> packager looked at it.
> -repeatability. More chance that the user's install will succeed and
> function as intended.
> -availability. Tarballs can be mirrored on their site to increase
> availability (and a recent email from Stuart Morgan indicates this is a
> non-trivial problem with GitHub).

So I still don't see how the Github tarball links fail to meet any of
those requirements. In case you're unaware, you can pull a tarball for
any SHA1 hash, and not simply tags and branch heads. While the tarballs
are only cached by Github for a brief period, and auto-generated
otherwise, their checksums are consistent.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

g8ecj at gilks

May 8, 2012, 2:52 AM

Post #15 of 24 (811 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

> On 05/04/2012 08:57 PM, Jean-Yves Avenard wrote:
>> Hi
>>
>> On Saturday, 5 May 2012, Nick Morrott wrote:
>>> On 4 May 2012 23:11, Michael T. Dean
>>>
>>> On a related note: are there any plans to upload nightly 0.2x-fixes
>>> tarballs and make those available instead (or even in addition) of the
>>> release/point release tarballs on the official website, for those
>>> users who do not checkout from github or use pre-built binaries?
>> IMHO; that's what point release are for.
>
> Yeah, I don't think it's worth doing nightly tarballs or anything.
>
> Then again, I'd love to just remove the tarballs from our website and
> let users/packagers either clone the repo with git or use github tarball
> links. TTBOMK, this would actually work, now, since Stuart M modified
> the version script to allow us to always keep a VERSION file in place,
> such that it's only used on systems without git tools or where the
> tarball contains a git export (rather than a repo).
>
> With that approach--as long as we post the -fixes tarball link rather
> than the release tag tarball link--users would still get the
> most-current fixes.
>
> Mike

Is there any chance that the packaging scripts could use this approach?
The Gentoo builds of 0.25 are now a month old and are for a release
candidate. I assume that the others (OSX, Win32, rpm etc) are in the same
position.

--
Robin Gilks

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

raymond at wagnerrp

May 8, 2012, 5:35 AM

Post #16 of 24 (811 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 5/8/2012 05:52, Robin Gilks wrote:
>
>> On 05/04/2012 08:57 PM, Jean-Yves Avenard wrote:
>>> Hi
>>>
>>> On Saturday, 5 May 2012, Nick Morrott wrote:
>>>> On 4 May 2012 23:11, Michael T. Dean
>>>>
>>>> On a related note: are there any plans to upload nightly 0.2x-fixes
>>>> tarballs and make those available instead (or even in addition) of the
>>>> release/point release tarballs on the official website, for those
>>>> users who do not checkout from github or use pre-built binaries?
>>> IMHO; that's what point release are for.
>>
>> Yeah, I don't think it's worth doing nightly tarballs or anything.
>>
>> Then again, I'd love to just remove the tarballs from our website and
>> let users/packagers either clone the repo with git or use github tarball
>> links. TTBOMK, this would actually work, now, since Stuart M modified
>> the version script to allow us to always keep a VERSION file in place,
>> such that it's only used on systems without git tools or where the
>> tarball contains a git export (rather than a repo).
>>
>> With that approach--as long as we post the -fixes tarball link rather
>> than the release tag tarball link--users would still get the
>> most-current fixes.
>>
>> Mike
>
> Is there any chance that the packaging scripts could use this approach?
> The Gentoo builds of 0.25 are now a month old and are for a release
> candidate. I assume that the others (OSX, Win32, rpm etc) are in the same
> position.
>

No. Any sensible package system is going to apply one or more hashes to
distributed binary or source tarballs, and fail on a mismatch. Use of a
single changing source tarball for those packaging scripts would not be
compatible, hence the ebuild generator in the Gentoo folder. I believe
the proper incantation is...

scripts/mythtv-buildebuild.py --version=0.25 --type=5

which pulls a new tarball of the latest commit to the 0.25/fixes branch
from Github, and produces a new ebuild based off the previous copy.
Ideally, I get some auto-build mechanism set up like MythBuntu, which
generates a new ebuild every night, test compiles it, and pushes to the
repository.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

g8ecj at gilks

May 8, 2012, 2:03 PM

Post #17 of 24 (806 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

> No. Any sensible package system is going to apply one or more hashes to
> distributed binary or source tarballs, and fail on a mismatch. Use of a
> single changing source tarball for those packaging scripts would not be
> compatible, hence the ebuild generator in the Gentoo folder. I believe
> the proper incantation is...
>
> scripts/mythtv-buildebuild.py --version=0.25 --type=5
>
> which pulls a new tarball of the latest commit to the 0.25/fixes branch
> from Github, and produces a new ebuild based off the previous copy.
> Ideally, I get some auto-build mechanism set up like MythBuntu, which
> generates a new ebuild every night, test compiles it, and pushes to the
> repository.

Sounds ideal - unfortunately:

# scripts/mythtv-buildebuild.py --version=0.25 --type=5
Traceback (most recent call last):
File "scripts/mythtv-buildebuild.py", line 312, in <module>
Ebuild(package).update()
File "scripts/mythtv-buildebuild.py", line 79, in update
self.get_cur()
File "scripts/mythtv-buildebuild.py", line 179, in get_cur
type = types.index(self.opts.type)
ValueError: tuple.index(x): x not in tuple

I'm afraid my python skills are not up to cryptic error messages like this :(

I'm open to suggestions...

Cheers

--
Robin Gilks

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

raymond at wagnerrp

May 8, 2012, 4:06 PM

Post #18 of 24 (797 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 5/8/2012 17:03, Robin Gilks wrote:
>> No. Any sensible package system is going to apply one or more hashes to
>> distributed binary or source tarballs, and fail on a mismatch. Use of a
>> single changing source tarball for those packaging scripts would not be
>> compatible, hence the ebuild generator in the Gentoo folder. I believe
>> the proper incantation is...
>>
>> scripts/mythtv-buildebuild.py --version=0.25 --type=5
>>
>> which pulls a new tarball of the latest commit to the 0.25/fixes branch
>> from Github, and produces a new ebuild based off the previous copy.
>> Ideally, I get some auto-build mechanism set up like MythBuntu, which
>> generates a new ebuild every night, test compiles it, and pushes to the
>> repository.
>
> Sounds ideal - unfortunately:
>
> # scripts/mythtv-buildebuild.py --version=0.25 --type=5
> Traceback (most recent call last):
> File "scripts/mythtv-buildebuild.py", line 312, in <module>
> Ebuild(package).update()
> File "scripts/mythtv-buildebuild.py", line 79, in update
> self.get_cur()
> File "scripts/mythtv-buildebuild.py", line 179, in get_cur
> type = types.index(self.opts.type)
> ValueError: tuple.index(x): x not in tuple

I couldn't remember if I had it take the value or the string. Try
'--type=fixes'.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

g8ecj at gilks

May 8, 2012, 6:31 PM

Post #19 of 24 (796 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

> I couldn't remember if I had it take the value or the string. Try
> '--type=fixes'.

No go with 'fixes' but 'p' seems to do something useful (I guessed from
the contents of lines 141, 148 & 169) , I'm just not sure what!!

jupiter Gentoo # scripts/mythtv-buildebuild.py --version=0.25 --type=fixes
Traceback (most recent call last):
File "scripts/mythtv-buildebuild.py", line 312, in <module>
Ebuild(package).update()
File "scripts/mythtv-buildebuild.py", line 79, in update
self.get_cur()
File "scripts/mythtv-buildebuild.py", line 179, in get_cur
type = types.index(self.opts.type)
ValueError: tuple.index(x): x not in tuple
jupiter Gentoo #
jupiter Gentoo # scripts/mythtv-buildebuild.py --version=0.25 --type=p
Autoselecting hash: 7fbcfb4b862069d9caa2c61c811b8602327f6552
mythtv-0.25_rc20120329 --> mythtv-0.25_p20120507
mytharchive-0.25_rc20120329 --> mytharchive-0.25_p20120507
mythbrowser-0.25_rc20120329 --> mythbrowser-0.25_p20120507
mythgallery-0.25_rc20120329 --> mythgallery-0.25_p20120507
mythgame-0.25_rc20120329 --> mythgame-0.25_p20120507
mythmusic-0.25_rc20120329 --> mythmusic-0.25_p20120507
mythnetvision-0.25_rc20120329 --> mythnetvision-0.25_p20120507
mythnews-0.25_rc20120329 --> mythnews-0.25_p20120507
mythweather-0.25_rc20120329 --> mythweather-0.25_p20120507
mythzoneminder-0.25_rc20120329 --> mythzoneminder-0.25_p20120507
mythtv-bindings-0.25_rc20120329 --> mythtv-bindings-0.25_p20120507

Cheers

--
Robin Gilks

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

knowledgejunkie at gmail

May 9, 2012, 5:39 AM

Post #20 of 24 (790 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 5 May 2012 02:15, Boleslaw Ciesielski <bc-mythtv [at] comcast> wrote:
> On Saturday, 5 May 2012, Nick Morrott wrote:
>>
>> On a related note: are there any plans to upload nightly 0.2x-fixes
>> tarballs and make those available instead (or even in addition) of the
>> release/point release tarballs on the official website, for those
>> users who do not checkout from github or use pre-built binaries?
>>
>> Cheers,
>> Nick
>
> You can always get the latest tarball at
> https://github.com/MythTV/mythtv/tarball/fixes/0.25
>
> Though I have to say that it seems a bit wasteful if you are doing it
> frequently. Better just checkout from git.

I was playing Devil's Advocate here. *We* all know the best ways of
getting the source - the issue is whether providing a stale tarball is
in anyone's interest when it is so easy to provide a link to either a
current Github tarball or to the repo clone instructions instead.

Many projects with code hosted on services which do not offer this
service provide nightly snapshots, hence the question. Providing a
release-day 0.25 tarball with known bugs that are already fixed in
0.25-fixes is in no-one's interest.

Cheers,
Nick

--
Nick Morrott

MythTV Official wiki: http://mythtv.org/wiki/
MythTV users list archive: http://www.gossamer-threads.com/lists/mythtv/users

"An investment in knowledge always pays the best interest." - Benjamin Franklin
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

ctreleaven at cogeco

May 10, 2012, 11:36 AM

Post #21 of 24 (772 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

At 4:19 PM -0400 5/6/12, Raymond Wagner wrote:
>On 5/6/2012 15:59, Craig Treleaven wrote:
>>At 1:42 AM -0400 5/5/12, Michael T. Dean wrote:
>>>Yeah, I don't think it's worth doing nightly tarballs or anything.
>>>
>>>Then again, I'd love to just remove the tarballs from our website and
>>>let users/packagers either clone the repo with git or use github
>>>tarball links.
>>>
>>
>>Mike, I was looking at packaging Myth for OS X via MacPorts. The folks
>>there are strongly biased against pulling from version control systems
>>because:
>>-security. Verifying checksums on a tarball gives quite strong
>>assurance that no malicious changes have been introduced since the
>>packager looked at it.
>>-repeatability. More chance that the user's install will succeed and
>>function as intended.
>>-availability. Tarballs can be mirrored on their site to increase
>>availability (and a recent email from Stuart Morgan indicates this is a
>>non-trivial problem with GitHub).
>
>So I still don't see how the Github tarball links fail to meet any
>of those requirements. In case you're unaware, you can pull a
>tarball for any SHA1 hash, and not simply tags and branch heads.
>While the tarballs are only cached by Github for a brief period, and
>auto-generated otherwise, their checksums are consistent.

Sorry for being dense but how do I go about pulling a tarball for a
specific commit hash? I downloaded a zipball of the latest fixes and
the link was:

https://nodeload.github.com/MythTV/mythtv/zipball/fixes/0.25

This got me MythTV-mythtv-v0.25-84-g9ccfac1.zip

How can I fetch this again (say with curl)?

Craig

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

raymond at wagnerrp

May 10, 2012, 12:44 PM

Post #22 of 24 (770 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 5/10/2012 14:36, Craig Treleaven wrote:
> At 4:19 PM -0400 5/6/12, Raymond Wagner wrote:
>> So I still don't see how the Github tarball links fail to meet any of
>> those requirements. In case you're unaware, you can pull a tarball
>> for any SHA1 hash, and not simply tags and branch heads. While the
>> tarballs are only cached by Github for a brief period, and
>> auto-generated otherwise, their checksums are consistent.
>
> Sorry for being dense but how do I go about pulling a tarball for a
> specific commit hash? I downloaded a zipball of the latest fixes and
> the link was:
>
> https://nodeload.github.com/MythTV/mythtv/zipball/fixes/0.25
>
> This got me MythTV-mythtv-v0.25-84-g9ccfac1.zip
>
> How can I fetch this again (say with curl)?

https://github.com/MythTV/mythtv/zipball/9ccfac11f31d8d05d48092efcbec8015c68f6cc1
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mark at mrobinson

May 10, 2012, 9:04 PM

Post #23 of 24 (766 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

Turns out the problem was the hue was set to zero instead of 50.

Tres odd.

Mark

On Fri, May 4, 2012 at 1:32 PM, Michael T. Dean <mtdean [at] thirdcontact>wrote:

> On 05/04/2012 04:07 PM, Mark Robinson wrote:
>
>> On Fri, May 4, 2012 at 12:44 PM, Michael T. Dean wrote:
>>
>> On 05/04/2012 03:23 PM, Mark Robinson wrote:
>>>
>>> On Thu, May 3, 2012 at 9:41 PM, Raymond Wagner wrote:
>>>>
>>>> On 5/3/2012 23:39, Mark Robinson wrote:
>>>>>
>>>>> I just upgraded to MythTV-0.25-fixes and I've found a rather serious
>>>>>> decoding bug.
>>>>>>
>>>>>> If you use mythffplay to play a video file then the blue and red color
>>>>>> channels will be reversed.
>>>>>>
>>>>>> If I play the video on a different machine, it works fine.
>>>>>> If I play the video using Xine or mplayer on the same machine, it
>>>>>> works
>>>>>> fine.
>>>>>>
>>>>>> Only mythffplay causes problems.
>>>>>>
>>>>>> If `mythffplay` doesn't work, the best option would be to disable
>>>>> it, or
>>>>> just simply not use it. MythTV's diagnostic playback tool is
>>>>> `mythavtest`.
>>>>> We added `mythffmpeg` to give a static copy of the ffmpeg transcoding
>>>>> utility for scripts to use, built off MythTV's internal snapshot of the
>>>>> ffmpeg libraries. `mythffplay` gets compiled for no reason other than
>>>>> we
>>>>> could.
>>>>>
>>>>> I've tried mythavtest. It also swaps the color channels.
>>>>
>>>>
>>>> Are you using a version of MythTV after Apr 13 (either 0.25-fixes or
>>> unstable/development/master)?
>>>
>>> https://github.com/MythTV/****mythtv/commit/0f8476995<https://github.com/MythTV/**mythtv/commit/0f8476995>
>>> <https:**//github.com/MythTV/mythtv/**commit/0f8476995<https://github.com/MythTV/mythtv/commit/0f8476995>
>>> >
>>>
>> I'm using 0.25-fixes.
>>
>
> Yes, but which revision.
>
> mythfrontend --version
>
>
>
> So I managed to 'solve' the problem by setting the video output driver to
>> be OpenGL rather than Xv. However, if I use mplayer or xine and force
>> them
>> to use the Xv output they work fine.
>>
>
> If you're using a new enough revision of 0.25-fixes, please go into
> playback with the Xv video renderer, and hit F (one or more times, as
> required), then adjust the hue--likely to either 0 or 50.
>
>
> Mike
> ______________________________**_________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/**listinfo/mythtv-dev<http://www.mythtv.org/mailman/listinfo/mythtv-dev>
>

jyavenard at gmail

May 11, 2012, 12:09 AM

Post #24 of 24 (766 views)
Permalink

Re: Found a severe decoding bug in mythffplay [In reply to]

On 11 May 2012 14:04, Mark Robinson <mark [at] mrobinson> wrote:
> Turns out the problem was the hue was set to zero instead of 50.
>
> Tres odd.
>
> Mark

the default value for the hue used to be set to 0 for anything but nvidia.

This is something that has been corrected a few weeks ago.

So either you're running an old version of myth, or: the value
wou;dn't have been corrected automatically if at any stage you edited
the value and did set it to 0
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads