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

Mailing List Archive: MythTV: Users

Jumping frames while editing

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


stichnot at gmail

Nov 1, 2009, 12:02 PM

Post #1 of 4 (525 views)
Permalink
Jumping frames while editing

When I edit a recording to set cut points, there is some odd behavior
when skipping backward or forward by N seconds. Instead of skipping
immediately to the desired frame, often it jumps through several
frames until it converges on the desired frame. For ATSC recordings
(mpeg2), there might be a couple of these intermediate frames. For
HD-PVR recordings (h.264), there could be up to 6 or 7.

I understand that this is how seeking works -- find the closest
keyframe and then advance frame by frame until the exact frame is
found. But is there something I can do to keep these intermediate
frames from being displayed to the screen?

This has been the case in 0.21 and 0.22, for many versions of the
nvidia driver through my current version (190.42). I see this with
the VDPAU profile and the Slim profile. I tried setting and unsetting
the "Seek to exact frame" setting, with no difference. The hardware
is a diskless single-core IONITX box.

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


J.Pilk at tesco

Nov 4, 2009, 3:37 PM

Post #2 of 4 (457 views)
Permalink
Re: Jumping frames while editing [In reply to]

Jim Stichnoth wrote:
> When I edit a recording to set cut points, there is some odd behavior
> when skipping backward or forward by N seconds. Instead of skipping
> immediately to the desired frame, often it jumps through several
> frames until it converges on the desired frame. For ATSC recordings
> (mpeg2), there might be a couple of these intermediate frames. For
> HD-PVR recordings (h.264), there could be up to 6 or 7.
>
> I understand that this is how seeking works -- find the closest
> keyframe and then advance frame by frame until the exact frame is
> found. But is there something I can do to keep these intermediate
> frames from being displayed to the screen?
>
> This has been the case in 0.21 and 0.22, for many versions of the
> nvidia driver through my current version (190.42). I see this with
> the VDPAU profile and the Slim profile. I tried setting and unsetting
> the "Seek to exact frame" setting, with no difference. The hardware
> is a diskless single-core IONITX box.
>
> Jim

I'm seeing something very like this on my box running 0.22-fixes from
ATrpms under CentOS 5.4, but not with the corresponding build on 64-bit
fc10. The CentOS box didn't do this in 0.21-fixes. Recordings are from
dvb. Both use nvidia, neither uses VDPAU. Drivers are 96.43.13, 190.42.
I'll do more experiments, but suggestions would be welcome.

While on the subject of the editor: I've often wondered why the time
counter isn't linked directly to the image I see; there's usually a
one-step hysteresis - i.e. an offset depending on the recent direction
of stepping. It works, but it feels correctable. I haven't identified
a ticket, or tried looking at the code :-(

John P




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


J.Pilk at tesco

Nov 11, 2009, 12:40 AM

Post #3 of 4 (433 views)
Permalink
Re: Jumping frames while editing [In reply to]

John Pilkington wrote:
> Jim Stichnoth wrote:
>> When I edit a recording to set cut points, there is some odd behavior
>> when skipping backward or forward by N seconds. Instead of skipping
>> immediately to the desired frame, often it jumps through several
>> frames until it converges on the desired frame. For ATSC recordings
>> (mpeg2), there might be a couple of these intermediate frames. For
>> HD-PVR recordings (h.264), there could be up to 6 or 7.
>>
>> I understand that this is how seeking works -- find the closest
>> keyframe and then advance frame by frame until the exact frame is
>> found. But is there something I can do to keep these intermediate
>> frames from being displayed to the screen?
>>
>> This has been the case in 0.21 and 0.22, for many versions of the
>> nvidia driver through my current version (190.42). I see this with
>> the VDPAU profile and the Slim profile. I tried setting and unsetting
>> the "Seek to exact frame" setting, with no difference. The hardware
>> is a diskless single-core IONITX box.
>>
>> Jim
>
> I'm seeing something very like this on my box running 0.22-fixes from
> ATrpms under CentOS 5.4, but not with the corresponding build on 64-bit
> fc10. The CentOS box didn't do this in 0.21-fixes. Recordings are from
> dvb. Both use nvidia, neither uses VDPAU. Drivers are 96.43.13, 190.42.
> I'll do more experiments, but suggestions would be welcome.


What I'm seeing looks as if it may be

http://svn.mythtv.org/trac/ticket/7523

although my first attempts at tweaking nvidia haven't entirely restored
normal operation.

Thanks to Mike Dean for pointing to this in

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

>
> While on the subject of the editor: I've often wondered why the time
> counter isn't linked directly to the image I see; there's usually a
> one-step hysteresis - i.e. an offset depending on the recent direction
> of stepping. It works, but it feels correctable. I haven't identified
> a ticket, or tried looking at the code :-(
>
> John P
>
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>


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


J.Pilk at tesco

Nov 14, 2009, 2:02 AM

Post #4 of 4 (402 views)
Permalink
Re: Jumping frames while editing [In reply to]

John Pilkington wrote:
> John Pilkington wrote:
>> Jim Stichnoth wrote:
>>> When I edit a recording to set cut points, there is some odd behavior
>>> when skipping backward or forward by N seconds. Instead of skipping
>>> immediately to the desired frame, often it jumps through several
>>> frames until it converges on the desired frame. For ATSC recordings
>>> (mpeg2), there might be a couple of these intermediate frames. For
>>> HD-PVR recordings (h.264), there could be up to 6 or 7.
>>>
>>> I understand that this is how seeking works -- find the closest
>>> keyframe and then advance frame by frame until the exact frame is
>>> found. But is there something I can do to keep these intermediate
>>> frames from being displayed to the screen?
>>>
>>> This has been the case in 0.21 and 0.22, for many versions of the
>>> nvidia driver through my current version (190.42). I see this with
>>> the VDPAU profile and the Slim profile. I tried setting and unsetting
>>> the "Seek to exact frame" setting, with no difference. The hardware
>>> is a diskless single-core IONITX box.
>>>
>>> Jim
>>
>> I'm seeing something very like this on my box running 0.22-fixes from
>> ATrpms under CentOS 5.4, but not with the corresponding build on
>> 64-bit fc10. The CentOS box didn't do this in 0.21-fixes. Recordings
>> are from dvb. Both use nvidia, neither uses VDPAU. Drivers are
>> 96.43.13, 190.42. I'll do more experiments, but suggestions would be
>> welcome.
>
>
> What I'm seeing looks as if it may be
>
> http://svn.mythtv.org/trac/ticket/7523
>
> although my first attempts at tweaking nvidia haven't entirely restored
> normal operation.
>
> Thanks to Mike Dean for pointing to this in
>
> http://www.gossamer-threads.com/lists/mythtv/users/406836
>
>>
>> While on the subject of the editor: I've often wondered why the time
>> counter isn't linked directly to the image I see; there's usually a
>> one-step hysteresis - i.e. an offset depending on the recent
>> direction of stepping. It works, but it feels correctable. I haven't
>> identified a ticket, or tried looking at the code :-(
>>
>> John P
>>

I had been seeing the second effect above for months, if not years.
After a few random changes to the frontend playback profiles it's
working as expected on both CentOS and F10 boxes. I'm wondering if, as
Yeechang Lee reported some time ago for the multirec settings, it only
works properly if the 'out-of-the-box' settings are confirmed by going
through the menu?

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

MythTV users 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.