Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

ffmpeg sync

 

 

First page Previous page 1 2 3 4 Next page Last page  View All MythTV dev RSS feed   Index | Next | Previous | View Threaded


mark at dclabs

May 16, 2007, 7:57 AM

Post #26 of 85 (3751 views)
Permalink
Re: ffmpeg sync [In reply to]

janne

Ive been running your ffmpeg sync for a while now and I think there is a
problem with ac3dec
it seems to sound "furry". audio quality is definitely reduced.
Im rebuilding without ac3_decoder and with liba52bin to double check things.
but not tonight.
this is a change from the previous ffmpeg which disabled ac3dec and used
liba52 only.
no other problems noticed so far but then again I only excercise mpeg2,.
xvid/mpeg4, mp3, mp2 and ac3.
Im also noticing some FE crashes too but not sure if they are related and
havent had time to chase them yet.

cheers
mark

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


bjm at lvcm

Jun 11, 2007, 10:46 AM

Post #27 of 85 (3684 views)
Permalink
Re: ffmpeg sync [In reply to]

Janne, I've been using the ffmpeg 8742 resync patch all along
as this clearly resolves MPEG-4 issues. I've retested the MPEG-2
issues I'd mentioned earlier. These may have been resolved by
other commits but I do not see broken frames with live channel
changes and I was able to play 10 out of 10 different DVDs with
no problems. Therefore I'd like to see this committed.

Bruce Markey wrote:
> Janne Grunau wrote:
>> On Tuesday 17 April 2007 20:58:44 Bruce Markey wrote:
>>>
>> Updated patch: http://www.grunau.be/ffmpeg_sync_8742_13272.diff.bz2
>
> I've been using this in production for several days to look
> for MPEG-4 problems and it seems pretty solid. I had tested
> recording a 90min rebroadcast of a College Basketball game
> then playing it back at 3X smooth motion and didn't find any
> broken frames or artifacts. The current SVN did have occasional
> encoding problems in addition to the decode problems you fixed.
> The encoding problems (assumed because the same artifacts would
> appear when played with and earlier frontend) were harder to
> isolate so I never followed up. However, the 8742 patch does
> not have these and this is an improvement.
>
> I tested the DCT encoding and interlace motion options. These
> do increase the CPU usage though I can't say that I can identify
> a difference in the video. These had been broken in a earlier
> version of myth's ffmpeg but do appear to work in current SVN
> and with this patch. So, MPEG-4 seems to be good.

I've been using these settings for transcodes and while it takes
more CPU time, image quality is still very good at low bitrates.

> MPEG-2... not so good. If I go to Watch TV and "Y" to an ivtv
> card then press the up arrow to change channels every few seconds,
> about half the time there are broken frame between the old and
> new channel playback. These appear to be broken frame artifacts
> from the old channel before playback starts for the new channel.

In over 100 channel changes, I didn't see this even once again.

> Next, if I hit left arrow, or any other button that will back up
> into the previous channel recorded, the current channel image
> will break up before playback restarts from the other recorded
> file.

Again, I cannot reproduce.

> Next, I tried DVD playback but after trying 4 or 5 DVD, I never
> got one to play a movie though I got a couple to show the vendor
> logos. The screen would remain black at the start of the chapter
> and the console would fill with messages like:
>
> ...
> [mpeg2video @ 0xb75b3f28]ac-tex damaged at 6 8
> [mpeg2video @ 0xb75b3f28]ac-tex damaged at 6 8
> [mpeg2video @ 0xb75b3f28]ac-tex damaged at 6 8
> ...

Each of the disks I use for testing now start with no decoding
errors. I suspect that applying the the patch may have tickled
a bug but one of the many DVD related changes have resolved the
underlying issue.

-- bjm

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


janne-mythtv at grunau

Jun 12, 2007, 1:35 AM

Post #28 of 85 (3676 views)
Permalink
Re: ffmpeg sync [In reply to]

On Monday 11 June 2007 19:46:22 Bruce Markey wrote:
> Janne, I've been using the ffmpeg 8742 resync patch all along
> as this clearly resolves MPEG-4 issues. I've retested the MPEG-2
> issues I'd mentioned earlier. These may have been resolved by
> other commits but I do not see broken frames with live channel
> changes and I was able to play 10 out of 10 different DVDs with
> no problems. Therefore I'd like to see this committed.

Thanks, that's good news. I have already the next sync in queue (with
hope that it would be better).
But as it seems that this one is ok now I'll fix the remaining issues
and try to commit it today.

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


janne-mythtv at grunau

Oct 12, 2007, 5:04 AM

Post #29 of 85 (3559 views)
Permalink
Re: ffmpeg sync [In reply to]

On Friday 12 October 2007 11:47:57 Nick F wrote:
> On 10/12/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
> > the next ffmpeg sync is overdue and working H.264 PAFF (since 9th
> > of october) in ffmpeg is an exellent opportunity.
>
> Great news. A quick (potentially dumb) question before I test the
> patch tonight. Will this also support MBAFF as used in BBC HD
> H.264transmissions, or is is just PAFF?

MBAFF is even without the patch supported though MBAFF and spatial
direct isn't.

> My one, and only, HD station is BBC HD via DVB-S, and I'd love to get
> it working. I tried last night (before this patch) on trunk svn
> 14660, and it was 'almost' playing smoothly - so hoping this might
> push me over the edge.

If it were PAFF the frontend would have segfaulted in seconds. There are
some general improvements in h264 decoding speed which might be enough,
the multithreaded decoder scales good as long the stream uses multiple
slices and and the supported deblocking types.

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


reidjr at btconnect

Oct 13, 2007, 3:01 AM

Post #30 of 85 (3539 views)
Permalink
Re: ffmpeg sync [In reply to]

Mark Kendall wrote:
> On 10/12/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
>
>> Please test and report any problems. Patches apply with -p2.
>>
>
> Janne
>
> Patches applied cleanly and compiled without problem.
>
> No obvious issues over a couple of hours of viewing.
>
> BBC-HD (DVB-S) is still problematic - it is clearly using both cores
> (Core2Duo E6600) but one is pegged at almost 100%, the other 60-80%
> and I get minor pauses every 3-4 seconds. Live tv is worse than
> recorded material.

Shame, saved me the trouble of going any further with my e4300 on BBC
HD. I get about 60% both cores with coreavc.

One thought though, is Janne's skiploop patch still there ?? That could
cut your cpu usage considerably.

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


reidjr at btconnect

Oct 13, 2007, 3:24 PM

Post #31 of 85 (3504 views)
Permalink
Re: ffmpeg sync [In reply to]

John wrote:
> Mark Kendall wrote:
>
>> On 10/12/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
>>
>>
>>> Please test and report any problems. Patches apply with -p2.
>>>
>>>
>> Janne
>>
>> Patches applied cleanly and compiled without problem.
>>
>> No obvious issues over a couple of hours of viewing.
>>
>> BBC-HD (DVB-S) is still problematic - it is clearly using both cores
>> (Core2Duo E6600) but one is pegged at almost 100%, the other 60-80%
>> and I get minor pauses every 3-4 seconds. Live tv is worse than
>> recorded material.
>>
>
> Shame, saved me the trouble of going any further with my e4300 on BBC
> HD. I get about 60% both cores with coreavc.
>
> One thought though, is Janne's skiploop patch still there ?? That could
> cut your cpu usage considerably.
>
> john
>
Thought I would try it anyway but I seem to have tripped over a gcc bug
( ??) A quick Google found exactly the compile error I was getting.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13850

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


mythtv at grumpydevil

Oct 13, 2007, 4:53 PM

Post #32 of 85 (3515 views)
Permalink
Re: ffmpeg sync [In reply to]

Mark Kendall wrote:
> On 10/12/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
>
>> Please test and report any problems. Patches apply with -p2.
>>
>
> Janne
>
> Patches applied cleanly and compiled without problem.
>
> No obvious issues over a couple of hours of viewing.
>
> BBC-HD (DVB-S) is still problematic - it is clearly using both cores
> (Core2Duo E6600) but one is pegged at almost 100%, the other 60-80%
> and I get minor pauses every 3-4 seconds. Live tv is worse than
> recorded material.
>
> Regards
>
> Mark
>
With a AMD X2 4600+ i get both cores regularly going to 90% load on
BBC-HD. Problem is that the video is not fluent though, lots of
micro-pauses. Its almost watchable....

Currently running a recording to test from a recording.

HD recorded from Film1-HD seems to run smoothly. A recording from HD-NL
(shadows final tour) is stuttering though, even with processor load of
both cores not going above 40%

Cheers,

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


janne-mythtv at grunau

Oct 13, 2007, 6:36 PM

Post #33 of 85 (3523 views)
Permalink
Re: ffmpeg sync [In reply to]

On Sunday 14 October 2007 01:53:39 Rudy Zijlstra wrote:
> Mark Kendall wrote:
> > On 10/12/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
> >> Please test and report any problems. Patches apply with -p2.
> >
> > No obvious issues over a couple of hours of viewing.
> >
> > BBC-HD (DVB-S) is still problematic - it is clearly using both
> > cores (Core2Duo E6600) but one is pegged at almost 100%, the other
> > 60-80% and I get minor pauses every 3-4 seconds. Live tv is worse
> > than recorded material.
> >
> With a AMD X2 4600+ i get both cores regularly going to 90% load on
> BBC-HD. Problem is that the video is not fluent though, lots of
> micro-pauses. Its almost watchable....
>
> Currently running a recording to test from a recording.
>
> HD recorded from Film1-HD seems to run smoothly. A recording from
> HD-NL (shadows final tour) is stuttering though, even with processor
> load of both cores not going above 40%

please try attached patch.

Janne
Attachments: fix_pts_handling.diff (0.66 KB)


janne-mythtv at grunau

Oct 14, 2007, 4:03 AM

Post #34 of 85 (3523 views)
Permalink
Re: ffmpeg sync [In reply to]

On Sunday 14 October 2007 05:14:44 Ben Dailey wrote:
>
> Patches applied cleanly and compiled. Is there a particular reason
> --disable-audio-oss was removed from configure?

No, that happened accidently. ffmpeg has probably renamed the option.
I'll fix it, thanks.

> It also seems that
> MPEG2VIDEO_XVMC codec did not build. I received a message about could
> not open codec MPEG2VIDEO_XVMC followed by a seg fault when trying to
> watch a 1080 ATSC recording.

XvMC doesn't work atm, also a merge issue. I'll look into it.
Nevertheless the frontend shouldn't segfault and I don't see a segfault
but the froneted chooses a different renderer.

> Let me know what additional testing or info I can provide to you.

I will reply with an updated patch when I'm fixed the issues.

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


mythtv at grumpydevil

Oct 14, 2007, 4:47 AM

Post #35 of 85 (3519 views)
Permalink
Re: ffmpeg sync [In reply to]

Janne Grunau wrote:
> On Sunday 14 October 2007 01:53:39 Rudy Zijlstra wrote:
>
>> Mark Kendall wrote:
>>
>>> On 10/12/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
>>>
>>>> Please test and report any problems. Patches apply with -p2.
>>>>
>>> No obvious issues over a couple of hours of viewing.
>>>
>>> BBC-HD (DVB-S) is still problematic - it is clearly using both
>>> cores (Core2Duo E6600) but one is pegged at almost 100%, the other
>>> 60-80% and I get minor pauses every 3-4 seconds. Live tv is worse
>>> than recorded material.
>>>
>>>
>> With a AMD X2 4600+ i get both cores regularly going to 90% load on
>> BBC-HD. Problem is that the video is not fluent though, lots of
>> micro-pauses. Its almost watchable....
>>
>> Currently running a recording to test from a recording.
>>
>> HD recorded from Film1-HD seems to run smoothly. A recording from
>> HD-NL (shadows final tour) is stuttering though, even with processor
>> load of both cores not going above 40%
>>
>
> please try attached patch.
>
> Janne
>
Janne,

I think you have nailed it. Recordings from BBC-HD are fluent now. Will
test live TV later today (at the moment they seem not to broadcast BBC-HD)

playback of recordings from film1-HD has also improved.

HD-NL recordings with EXQI branding on left hand side are still not OK.
Its as if i get dropped frames.


Very good improvement!


Cheers,

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


mythtv at grumpydevil

Oct 14, 2007, 6:49 AM

Post #36 of 85 (3505 views)
Permalink
Re: ffmpeg sync [In reply to]

Rudy Zijlstra wrote:
> Janne Grunau wrote:
>
>> On Sunday 14 October 2007 01:53:39 Rudy Zijlstra wrote:
>>
>>
>>> Mark Kendall wrote:
>>>
>>>
>>>> On 10/12/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
>>>>
>>>>
>>>>> Please test and report any problems. Patches apply with -p2.
>>>>>
>>>>>
>>>> No obvious issues over a couple of hours of viewing.
>>>>
>>>> BBC-HD (DVB-S) is still problematic - it is clearly using both
>>>> cores (Core2Duo E6600) but one is pegged at almost 100%, the other
>>>> 60-80% and I get minor pauses every 3-4 seconds. Live tv is worse
>>>> than recorded material.
>>>>
>>>>
>>>>
>>> With a AMD X2 4600+ i get both cores regularly going to 90% load on
>>> BBC-HD. Problem is that the video is not fluent though, lots of
>>> micro-pauses. Its almost watchable....
>>>
>>> Currently running a recording to test from a recording.
>>>
>>> HD recorded from Film1-HD seems to run smoothly. A recording from
>>> HD-NL (shadows final tour) is stuttering though, even with processor
>>> load of both cores not going above 40%
>>>
>>>
>> please try attached patch.
>>
>> Janne
>>
>>
> Janne,
>
> I think you have nailed it. Recordings from BBC-HD are fluent now. Will
> test live TV later today (at the moment they seem not to broadcast BBC-HD)
>
> playback of recordings from film1-HD has also improved.
>
> HD-NL recordings with EXQI branding on left hand side are still not OK.
> Its as if i get dropped frames.
>
>
> Very good improvement!
>
>
> Cheers,
>
> Rudy
>
And just now testing BBC-HD in liveTV mode. It also works. No stuttering.

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


reidjr at btconnect

Oct 14, 2007, 2:36 PM

Post #37 of 85 (3491 views)
Permalink
Re: ffmpeg sync [In reply to]

Janne Grunau wrote:
> On Sunday 14 October 2007 01:53:39 Rudy Zijlstra wrote:
>
>> Mark Kendall wrote:
>>
>>> On 10/12/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
>>>
>>>> Please test and report any problems. Patches apply with -p2.
>>>>
>>> No obvious issues over a couple of hours of viewing.
>>>
>>> BBC-HD (DVB-S) is still problematic - it is clearly using both
>>> cores (Core2Duo E6600) but one is pegged at almost 100%, the other
>>> 60-80% and I get minor pauses every 3-4 seconds. Live tv is worse
>>> than recorded material.
>>>
>>>
>> With a AMD X2 4600+ i get both cores regularly going to 90% load on
>> BBC-HD. Problem is that the video is not fluent though, lots of
>> micro-pauses. Its almost watchable....
>>
> please try attached patch.
>
> Janne
>
>

Once I got over the apparent dependency on gcc version (gcc-2.95 and
gcc-4.1 both failed to compile the ffmpeg patch for some reason, seems
like a known issue) and compiled with gcc-3.4, I used both the main, and
additional patch.

On a e4300 (1.8GHz core2duo) I could watch BBC-HD with glitches every
second, even though the resource meter suggested I was using only 80% CPU.

Overclocked the e4300 to 2.4GHz, and I was getting 75-80% cpu, evenly
across both cores, and smooth playback. Excellent, so at least on the
samples I tried, the slice based multi threading (whatever that means
:-) ) was working perfectly for BBC-HD.

For performance comparison :

I run my 2 "production" frontends on a single cored 3200+ Athlon64 and
on a e4300 core2duo. I am currently running svn r14404, (last before
myth-vid sync) with a patch to allow coreavc support. With everything
turned off (de-interlacing, de-blocking) I get about 60% across both
cores on the e4300 watching on a 1680x1050 monitor.

I am using the 3200+ as a living room box teamed up with a SD CRT TV. I
was surprised to find I NEARLY get away with watching BBC-HD (albeit
scaled to SD through tv out on an nvidia 6200 card). The 3200+, is
running at stock speed in an IWILL ZPCsp64. Unfortunately its a great
little bookshelf PC, but the BIOS doesn't allow any over clock. I have
the ddr400 ram as a matched 256M pair, in dual channel mode. The ram
bandwidth seems to make a difference, and I can watch BBC-HD with few
enough glitches to be bearable.

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


janne-mythtv at grunau

Oct 14, 2007, 2:49 PM

Post #38 of 85 (3487 views)
Permalink
Re: ffmpeg sync [In reply to]

On Sunday 14 October 2007 23:36:26 John wrote:
>
> Once I got over the apparent dependency on gcc version (gcc-2.95 and
> gcc-4.1 both failed to compile the ffmpeg patch for some reason,
> seems like a known issue) and compiled with gcc-3.4, I used both the
> main, and additional patch.

It builds here with gcc 4.1.2 (32 bit and 64 bit). It would be nice if
you can give details of your system and the build failure.

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


reidjr at btconnect

Oct 14, 2007, 3:16 PM

Post #39 of 85 (3478 views)
Permalink
Re: ffmpeg sync [In reply to]

Janne Grunau wrote:
> On Sunday 14 October 2007 23:36:26 John wrote:
>
>> Once I got over the apparent dependency on gcc version (gcc-2.95 and
>> gcc-4.1 both failed to compile the ffmpeg patch for some reason,
>> seems like a known issue) and compiled with gcc-3.4, I used both the
>> main, and additional patch.
>>
>
> It builds here with gcc 4.1.2 (32 bit and 64 bit). It would be nice if
> you can give details of your system and the build failure.
>
> Janne
>
>
the failure message was as I posted above, and seemed to be a known
ffmpeg /compiler problem.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13850

can't find a register in class `GENERAL_REGS' while reloading `asm'

I was originally set up with gcc-4.1 (GCC) 4.1.2 20061115 (prerelease)
(Debian 4.1.1-20), and was trying to compile it on my backend which is a
DURON1600 (athlonXP). The bug report seemed to suggest that it was
non-determenistic which seems bizarre.

I was just about to see if I could reuse your skiploopfilter patch from
a few months back, but was allready at the "too difficult" stage. Any
chance that you could get that into any commit. Always good to be able
to ease of the cpu if possible.

Thanks for all your efforts, much appreciated.

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


reidjr at btconnect

Oct 20, 2007, 8:08 AM

Post #40 of 85 (3446 views)
Permalink
Re: ffmpeg sync [In reply to]

John wrote:
> <snip>
>
> On a e4300 (1.8GHz core2duo) I could watch BBC-HD with glitches every
> second, even though the resource meter suggested I was using only 80% CPU.
>
> Overclocked the e4300 to 2.4GHz, and I was getting 75-80% cpu, evenly
> across both cores, and smooth playback. Excellent, so at least on the
> samples I tried, the slice based multi threading (whatever that means
> :-) ) was working perfectly for BBC-HD.
>
> <snip>

I have updated Janne's -skiploop patch, just so it applies to SVN
(14698). This makes a real difference to CPU usage. The patch disables
deblocking, and unloads the CPU.

For performance comparison:
Watching smooth BBC-HD.
Without patch 2.4GHz core2duo running at 80% on both cores.
With Patch 1.8GHz core2duo running at 65% on both cores.

You need all of the previous patches :

ffmpeg_sync_10712_14666_0.diff
0001-enable-multithreaded-video-stream-decoding.patch
fix_pts_handling.diff

plus this little update (originally provided by Janne).

ffmpeg_skiploop_14698.diff

Deblocking is ENABLED by default. to disable you need to add an entry in
the myth database.

http://www.gossamer-threads.com/lists/mythtv/users/254646#254646

"To activate it you have run following sql statement. $YOUR_HOST is the
hostname of the frontend host.

INSERT INTO settings (value, data, hostname) VALUES ("AVSkipLoopFilter",
1, $YOUR_HOST);

Janne"


John
Attachments: ffmpeg_skiploop_14698.diff (2.06 KB)


reidjr at btconnect

Oct 20, 2007, 1:00 PM

Post #41 of 85 (3413 views)
Permalink
Re: ffmpeg sync [In reply to]

John wrote:
> Janne Grunau wrote:
>> On Sunday 14 October 2007 23:36:26 John wrote:
>>
>>> Once I got over the apparent dependency on gcc version (gcc-2.95 and
>>> gcc-4.1 both failed to compile the ffmpeg patch for some reason,
>>> seems like a known issue) and compiled with gcc-3.4, I used both the
>>> main, and additional patch.
>>>
>>
>> It builds here with gcc 4.1.2 (32 bit and 64 bit). It would be nice
>> if you can give details of your system and the build failure.
>>
>> Janne
>>
>>
> the failure message was as I posted above, and seemed to be a known
> ffmpeg /compiler problem.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13850
>
> can't find a register in class `GENERAL_REGS' while reloading `asm'
>
> I was originally set up with gcc-4.1 (GCC) 4.1.2 20061115 (prerelease)
> (Debian 4.1.1-20), and was trying to compile it on my backend which is
> a DURON1600 (athlonXP). The bug report seemed to suggest that it was
> non-determenistic which seems bizarre.
>
> I was just about to see if I could reuse your skiploopfilter patch
> from a few months back, but was allready at the "too difficult" stage.
> Any chance that you could get that into any commit. Always good to be
> able to ease of the cpu if possible.
>
> Thanks for all your efforts, much appreciated.
>
> John
The gcc version may have been a red herring ... or maybe not, I havn't
tried all possible combinations yet.

But :
After much messing around I realised I was using --enable-proc-opt to
try and wring the last clock cycle out of my machines. If I compiled on
my backend (Duron1600) it was compiling with -march=athlon , which would
fail, whereas the core2duo was -march=K8. -march=K8 would compile, and
-march=athlon would not. (and -march=K8 dies with illegal instruction on
my Duron back end -- surprise). The default -march=pentiumpro works on
all my machines, and I cant see any performance difference on playing
back h264. I had expected a measurable difference when optimized against
the newer processors.

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


janne-mythtv at grunau

Oct 30, 2007, 2:04 PM

Post #42 of 85 (3264 views)
Permalink
Re: ffmpeg sync [In reply to]

On Tuesday 30 October 2007 05:40:48 Ben Dailey wrote:
>
> Patched and compiled clean here but --disable-oss has been removed as
> an option can use --disable-demuxer=oss in its place.

Restored in
http://www.grunau.be/ffmpeg_sync_10867_14763_1.diff.bz2

> XVMC is unavailable and causes mythfrontend to crash.

I can't get XvMC to work even with unpatched trunk. All I get is
a "xvmc-blit is unavaible falling back to ..."
My system is a 64-bit gentoo with nvidia binary drivers 100.14.19.

I think I've tried all possible XvMC configure switches without luck.
Even linking directly with libXvMCNVIDIA failed.

I'll postpone applying the pattch until I can solve this.

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


janne-mythtv at grunau

Oct 30, 2007, 2:12 PM

Post #43 of 85 (3267 views)
Permalink
Re: ffmpeg sync [In reply to]

On Tuesday 30 October 2007 05:40:48 Ben Dailey wrote:
> XVMC is unavailable and
> causes mythfrontend to crash. GDB Log is attached to this mail.

The backtrace looks very unrelated to XvMC. Have you tired it with
different files?
It crashes only if you enable XvMC in video decoder profiles? For the
same file?

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


funaho at jurai

Oct 30, 2007, 3:23 PM

Post #44 of 85 (3292 views)
Permalink
Re: ffmpeg sync [In reply to]

On 10/30/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
> I can't get XvMC to work even with unpatched trunk. All I get is
> a "xvmc-blit is unavaible falling back to ..."
> My system is a 64-bit gentoo with nvidia binary drivers 100.14.19.

The 100.14.19 drivers have some really annoying bugs relating to Xv
and XvMC; generally once you use one the other won't work until you
restart X. Usually I just get a "pink screen of death" when this
happens but on occasion it will crash my frontend. Other time I've
noticed that XvMC stops working, and stuff that *should* be playing
through XvMC such as 1080i broadcasts aren't anymore (I can always
tell, because my OSD goes back to color :) ). You might be running
into this problem or some version of it.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


janne-mythtv at grunau

Oct 30, 2007, 3:35 PM

Post #45 of 85 (3270 views)
Permalink
Re: ffmpeg sync [In reply to]

On Tuesday 30 October 2007 23:23:34 Joshua M. Thompson wrote:
> On 10/30/07, Janne Grunau <janne-mythtv [at] grunau> wrote:
> > I can't get XvMC to work even with unpatched trunk. All I get is
> > a "xvmc-blit is unavaible falling back to ..."
> > My system is a 64-bit gentoo with nvidia binary drivers 100.14.19.
>
> The 100.14.19 drivers have some really annoying bugs relating to Xv
> and XvMC; generally once you use one the other won't work until you
> restart X. Usually I just get a "pink screen of death" when this
> happens but on occasion it will crash my frontend.

Yeah, I've seeing this too but never expirienced a frontend crash. The
X-server restart is annoying.

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


janne-mythtv at grunau

Nov 1, 2007, 8:19 AM

Post #46 of 85 (3246 views)
Permalink
Re: ffmpeg sync [In reply to]

On Thursday 01 November 2007 15:20:37 Ben Dailey wrote:
>
> I have applied the ffmpeg_sync_10867_14763_2.diff patch against svn
> r14776 and it compiles (after uncommenting line 11 of
> libs/libmythtv/avformatdecoder.cpp [#include "mythconfig.h"]) and
> xvmc works for me now. The frontend still crashes on xvmc videos if I
> enable multithread support with the
> 0001-enable-multithreaded-video-stream-decoding.patch but that is a
> different issue.

Thanks, I'll look into it once I find time to get XvMC working again.

> Can I help do anymore testing so the ffmpeg sync
> patch can get applied to svn?

No, I would have applied it yesterday but the configure needed some
fixes. I'll apply it monday.

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


mythtv at grumpydevil

Nov 2, 2007, 3:05 AM

Post #47 of 85 (3198 views)
Permalink
Re: ffmpeg sync [In reply to]

Janne Grunau wrote:
> On Thursday 01 November 2007 15:20:37 Ben Dailey wrote:
>
>> I have applied the ffmpeg_sync_10867_14763_2.diff patch against svn
>> r14776 and it compiles (after uncommenting line 11 of
>> libs/libmythtv/avformatdecoder.cpp [#include "mythconfig.h"]) and
>> xvmc works for me now. The frontend still crashes on xvmc videos if I
>> enable multithread support with the
>> 0001-enable-multithreaded-video-stream-decoding.patch but that is a
>> different issue.
>>
>
> Thanks, I'll look into it once I find time to get XvMC working again.
>
>
>> Can I help do anymore testing so the ffmpeg sync
>> patch can get applied to svn?
>>
>
> No, I would have applied it yesterday but the configure needed some
> fixes. I'll apply it monday.
>
>
Thanks a lot! Will you also include the fix-pts-handling.diff patch?
That one is pretty essential for good watching :)

Rudy

P.S. currently running SVN 14785 with ffmpeg_sync_10867_14763_2.diff and
fix_pts_handling.diff applied.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mythtv at grumpydevil

Nov 2, 2007, 3:37 AM

Post #48 of 85 (3193 views)
Permalink
Re: ffmpeg sync [In reply to]

Janne Grunau wrote:
> On Thursday 01 November 2007 15:20:37 Ben Dailey wrote:
>
>> I have applied the ffmpeg_sync_10867_14763_2.diff patch against svn
>> r14776 and it compiles (after uncommenting line 11 of
>> libs/libmythtv/avformatdecoder.cpp [#include "mythconfig.h"]) and
>> xvmc works for me now. The frontend still crashes on xvmc videos if I
>> enable multithread support with the
>> 0001-enable-multithreaded-video-stream-decoding.patch but that is a
>> different issue.
>>
>
> Thanks, I'll look into it once I find time to get XvMC working again.
>
>
>> Can I help do anymore testing so the ffmpeg sync
>> patch can get applied to svn?
>>
>
> No, I would have applied it yesterday but the configure needed some
> fixes. I'll apply it monday.
>
> Janne
>
>
Related question, do not know whether this is correct thread, here goes:

mythtranscode at the moment when using -m parameter crashes on H.264
recordings. I habitually use:
mythtranscode -c <chan> -s <starttime> -m -l --showprogress -o
<file-name> to convert a recording to a stored mpg file.

This crashes though. Any idea when H.264 support will be added to
mythtranscode? Or should i use a different parameter? I have no wish to
transcode from H.264 to something else, i just want the additional
start, end and commercials to be gone...

Rudy

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


janne-mythtv at grunau

Nov 2, 2007, 3:54 AM

Post #49 of 85 (3205 views)
Permalink
Re: ffmpeg sync [In reply to]

On Friday 02 November 2007 11:05:13 Rudy Zijlstra wrote:
> Janne Grunau wrote:
> >> Can I help do anymore testing so the ffmpeg sync
> >> patch can get applied to svn?
> >
> > No, I would have applied it yesterday but the configure needed some
> > fixes. I'll apply it monday.
>
> Thanks a lot! Will you also include the fix-pts-handling.diff patch?

No, it is incorrect and might break other recordings

> That one is pretty essential for good watching :)

I'll apply a different fix for the problem.

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


janne-mythtv at grunau

Nov 2, 2007, 3:58 AM

Post #50 of 85 (3216 views)
Permalink
Re: ffmpeg sync [In reply to]

On Friday 02 November 2007 11:37:35 Rudy Zijlstra wrote:
>
> Related question, do not know whether this is correct thread, here
> goes:
>
> mythtranscode at the moment when using -m parameter crashes on H.264
> recordings. I habitually use:
> mythtranscode -c <chan> -s <starttime> -m -l --showprogress -o
> <file-name> to convert a recording to a stored mpg file.
>
> This crashes though.

mythtranscode --mpeg2 will only handle mpeg2, it shouldn't crash though.

> Any idea when H.264 support will be added to
> mythtranscode? Or should i use a different parameter? I have no wish
> to transcode from H.264 to something else, i just want the additional
> start, end and commercials to be gone...

That's currently not supported. Someone has to add H.264 logic to the
(mostly) lossless part of mythtranscode.

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

First page Previous page 1 2 3 4 Next page Last page  View All MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.