Mailing List Archive: MythTV: Dev

GOP_BYFRAME vs. GOP_START and mythcommflag --rebuild

Index | Next | Previous | View Threaded

doug at parkercat

Jun 4, 2007, 5:06 PM

Post #1 of 7 (1626 views)
Permalink

GOP_BYFRAME vs. GOP_START and mythcommflag --rebuild

Is there a reason that avformatdecoder creates positionmaps using
MARK_GOP_START (using keyframe number, assuming a fixed keyframe
interval) rather than MARK_GOP_BYFRAME (using frame number) by default?
Maybe non-avformatdecoder playback needs the other format?

When using mythcommflag --rebuild on an ATSC-sourced MPEG2 recording,
this results in a totally broken positionmap, since ATSC keyframes come
in at irregular intervals.

I've "fixed" this in my local tree by hardcoding the affected function
(AvFormatDecoder::OpenFile) to always use MARK_GOP_BYFRAME but I'm
wondering if there's a more general way to fix the problem. Currently
it chooses BYFRAME for avi files; perhaps it should do so for transport
streams as well? Or for everything?

Thanks for any comments,
-Doug

Attachments:

signature.asc (0.25 KB)

bolek-mythtv at curl

Jun 4, 2007, 5:14 PM

Post #2 of 7 (1560 views)
Permalink

Re: GOP_BYFRAME vs. GOP_START and mythcommflag --rebuild [In reply to]

Doug Larrick wrote:
> Is there a reason that avformatdecoder creates positionmaps using
> MARK_GOP_START (using keyframe number, assuming a fixed keyframe
> interval) rather than MARK_GOP_BYFRAME (using frame number) by default?
> Maybe non-avformatdecoder playback needs the other format?
>
> When using mythcommflag --rebuild on an ATSC-sourced MPEG2 recording,
> this results in a totally broken positionmap, since ATSC keyframes come
> in at irregular intervals.
>
> I've "fixed" this in my local tree by hardcoding the affected function
> (AvFormatDecoder::OpenFile) to always use MARK_GOP_BYFRAME but I'm
> wondering if there's a more general way to fix the problem. Currently
> it chooses BYFRAME for avi files; perhaps it should do so for transport
> streams as well? Or for everything?

I don't have the answer but there is a ticket for this:

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

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

level42 at sympatico

Jun 4, 2007, 9:07 PM

Post #3 of 7 (1549 views)
Permalink

Re: GOP_BYFRAME vs. GOP_START and mythcommflag --rebuild [In reply to]

Use mythtranscode --buildindex instead. This will only work for recordings,
if its a video (under mythvideo), you need the patch to ticket # 3533.

Actually, mythcommflag will sometimes create the MARK_GOP_START and
sometimes as MARK_GOP_BYFRAME . Just depends what the initial key frame
distance is in the file.

Also if it chooses MARK_GOP_BYFRAME it will almost always create a wrong
position map since it divides the frame # by the key frame distance. It
shouldn't, it should just store the frame # in the position map. When the
file is played back with a position map of MARK_GOP_BYFRAME, the key frame
distance is set to 1, which is not the same as when mythcommflag generated
the position map in the first place.

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

cpinkham at bc2va

Jun 4, 2007, 9:44 PM

Post #4 of 7 (1543 views)
Permalink

Re: GOP_BYFRAME vs. GOP_START and mythcommflag --rebuild [In reply to]

* On Tue Jun 05, 2007 at 12:07:02AM -0400, Bill wrote:
> Use mythtranscode --buildindex instead. This will only work for recordings,
> if its a video (under mythvideo), you need the patch to ticket # 3533.
>
> Actually, mythcommflag will sometimes create the MARK_GOP_START and
> sometimes as MARK_GOP_BYFRAME . Just depends what the initial key frame
> distance is in the file.

Actually, mythcommflag doesn't do much at all, it's the decoders doing
the work and that's what ticket #1088 references. It's on my TODO list and
in my ticket view, but is very low priority for me so if someone else wants
to submit a patch for 1088 then feel free to do so. :) I've been using and
programming on Myth for over 4 and a half years now and have not lost a
single table due to corruption. mythcommflag --rebuild just tells the
decoder to save it's positionmap after mythcommflag finishes 'playing' the
file, so the fix is in the decoder and player code, not in mythcommflag.

I'm not trying to jump on anyone's case, just trying to point people in
the right direction if anyone gets the urge to work on a fix for this. :)

I'm happy to review any patches, just attach them to ticket #1088 and
I'll see them.

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

level42 at sympatico

Jun 4, 2007, 10:58 PM

Post #5 of 7 (1550 views)
Permalink

Re: GOP_BYFRAME vs. GOP_START and mythcommflag --rebuild [In reply to]

Agreed about the decoders. Thanks for the clarification.

I've been looking at making a patch, to convert to use only GOP_BYFRAME, but
don't know what to do with the code

bool is_ivtv = (keyframedist == 15) || (keyframedist ==12);
positionMapType = (is_ivtv) ? MARK_GOP_START : MARK_GOP_BYFRAME;

in HandleGopStart in avformatdecoder.cpp.

I would tend to set keyframedist=1 and positionMapType=MARK_GOP_BYFRAME for
everything in both HandleGopStart and Openfile, but not sure about the ivtv
thing. I believe that these changes would allow mythcommflag to generate a
good position map.

I have a sneaking suspision that making these changes will help improve
seeking on mpg's without position maps, since the position map is stored
incorrectly if keyframdist is greater than 1 and changes during playback and
when the positionMapType gets set to MARK_GOP_BYFRAME.

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

level42 at sympatico

Jun 12, 2007, 8:51 PM

Post #6 of 7 (1495 views)
Permalink

Re: GOP_BYFRAME vs. GOP_START and mythcommflag --rebuild [In reply to]

Posted some code to Ticket #1088
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

cpinkham at bc2va

Jun 13, 2007, 7:25 AM

Post #7 of 7 (1478 views)
Permalink

Re: GOP_BYFRAME vs. GOP_START and mythcommflag --rebuild [In reply to]

* On Tue Jun 12, 2007 at 11:51:26PM -0400, Bill wrote:
> Posted some code to Ticket #1088

Thanks. I'll try to take a look at this tonight or tomorrow.

You can test the mpegrecorder without having an ivtv compatible card.
If you create a capturecard and set the cardtype to "MPEG" via
mythtv-setup or direct SQL, then you can set the videodevice to point
to a mpeg file instead of an actual capture card. The filename needs
to be prefixed by "file:" which is a flag to tell mpegrecorder that
this is a mpeg file not a capture card. I added this feature in for
testing a few years ago. It makes it easy to test on machines without
a real capture card as well as testing multiple capture cards when you
only have one in your dev machine. :) When I was writing the Storage
Groups code, I had 6 of these virtual tuners going at the same time
to test the load-balancing code.

My videodevice field for my virtual tuners looks like this:

file:/video3/mythtv/samples/samplempegfile.mpg

If the recorder reaches the end of the mpeg file it will start back
at the beginning. It even supports simulated channel changes via
the DummyChannel class so you can use it to test LiveTV changes.

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads