[outleradam]

The issue with mythtv displaying improper duration was fixed here in mythtv trac 9109( http://svn.mythtv.org/trac/ticket/9109#comment:33 )

XBMC is still not handling variable framerate MPEG2-TS. Should I start a TRAC ticket for improper handling of framecount in with comskip?

[dteirney]

The issue with mythtv displaying improper duration was fixed here in mythtv trac 9109( http://svn.mythtv.org/trac/ticket/9109#comment:33 )

XBMC is still not handling variable framerate MPEG2-TS. Should I start a TRAC ticket for improper handling of framecount in with comskip?

You can add a trac ticket, but I doubt anything will happen with it for possibly a long time. Everything in dvdplayer is based on the decode time stamp (dts). There is nothing that I know of that could be used to determine the number of the decoded frame that is currently being shown (which would be needed to trigger a skip), and nothing that supports jumping to the number of another decoded frame.

For this to properly work for variable frame rate files XBMC would have to read the keyframe mapping table in mythtv to find the nearest keyframe, find the associated timestamp and then interpolate as necessary (or just skip to the time with the nearest keyframe).

[outleradam]

It seems that a more general solution would be in order. Don't forget that variable framerates will be encountered in XBMC pvr branch. It would make more sense to expand the existing code to read frames as it plays back, and take action if required.

If we simply utilize mythtv information, then we've adapted to the current and ever changing mythtv environment. That leaves the same problem to be solved with sage, tvheadend, beyondtv and all the rest.

Variable framerate is becoming more popular and is the standard for cable companies. When dealing with raw data from cable or OTA sources, variable framerates will be encountered.

To me it would make more sense to process frame number in real time from the media source. Currently we preemptively calculate time based on initial or reported framerate. You are proposing to integrate more mythtv data into xbmc calculations. Here are sime ideas which would improve mpeg2-ts globally:

1. Monitor frame number as it crosses xbmc and generate EDL in real-time.
2. Monitor framerate as reported in real time and make corrections to the predetermined EDL as needed.

I understand that it is Better programming to be specific in an implementation, like supporting mythtv, but the problem here is that the speciffic format MPEG2-TS is not supported properly within XBMC.

[dteirney]

Variable framerate is becoming more popular and is the standard for cable companies. When dealing with raw data from cable or OTA sources, variable framerates will be encountered.

What standard are you referring to and what evidence do you have to support this?

[dteirney]

1. Monitor frame number as it crosses xbmc and generate EDL in real-time.
2. Monitor framerate as reported in real time and make corrections to the predetermined EDL as needed.

You missed out the most important (and hardest) part:
3. Introduce a way to seek to a frame number reliably

https://github.com/lbrandy/ffmpeg-fas might be a possibility to investigate, but that in itself is not a small piece of work.

[outleradam]

What standard are you referring to and what evidence do you have to support this?

Well, when my cable company in South Carolina introduced digital cable, it had problems with comskip. Now my cable company here has converted to digital and I'm experiencing the same problem. Cable companies were never required to switch to digital. They run proprietary networks. In order for framerate to be maintained, every commercial requires re-encoding to the same framerate as the currently playing channel.

ASTC standards allow for many frame formats ( 60p 59.94p, 30p, 29.97p, 24p, 23.976p, 60i, and 59.94i ). Each broadcaster can choose their framerate. Each rebroadcaster can choose to re-encode the commercials, or utilize another framerate in the ASTC standard.

It's my understanding that reencoding of a signal requires a frame loss somewhere (with the exception of 60i-30p). Rather then reencode re-broadcasters are choosing to re-broadcast the un-re-encoded commercial because that's what they're getting paid to do. Why re-encode a commercial that you were paid to broadcast as is?

I'm sure we'll be seeing much more of this issue as more people make the switch to PC based DVRs. The Walmart just started carrying those low powered PCs which were once reserved for us enthusiasts, and HDHomeRuns are $50 I believe this is the year of the media center.

[erittaf]

Just a bump from another affected user. I have XBMC on several windows based machines and any content that has variable framerate complications the commercial skipping gets off. This appears to be mostly in the digital cable channels and largely affecting 420p content. Most of the primetime HD stuff I record on Broadcast channels works out just fine. On the affected recordings, the farther into the video, the worse it gets. It seems the first commercial break lands in the correct spot, but each one after that gets farther and farther off. Is there a way to turn off commercial skipping in myth:// setups? All my google'ing seems to indicate there used to be an option but it was removed. Is this correct? **edit see note below** I guess I could turn off the commercial flagging on these recording rules but that isn't a great longterm solution for those of us that have multiple frontends on several different platforms. (MythTV frontend on my linux machine works just fine with commercial flagging.)

Still striving to make XBMC the center of a "wife-approved" caliber PVR.


***edit:***
I have managed to cheat my way into disabling most of the commercial skips that are giving me trouble by adding the following lines in the advancedsettings.xml file:

<edl>
<mergeshortcommbreaks>true</mergeshortcommbreaks>
<mincommbreaklength>600</mincommbreaklength>
</edl>

It's not elegant and the debug log shows me the mincommbreaklength number appears to cap at 300 so really long commercial breaks will still try to get skipped... not ideal but it works for everything that's not a feature film...

[outleradam]

That fix will do nothing. The problem stems from XBMC's inability to handle variable framerate video. IE... The content comes in 24fps and cable providers add in their commercials at 29fps or 60fps. This makes the comskips not line up properly throughout the duration of the video and the gap increases progressively.

The problem won't be fixed until XBMC's EDL methods properly handle MPEG2-TS standard.

We need someone to code it.

A fix would be to reencode each recording to a fixed framerate. However that consumes massive processor power and still does not repair XBMC's inability to handle MPEG2-TS Variable Framerate.

What is required is to either calculate or adjust EDL in real-time or to scan the video for framerate adjustments prior to implementing XBMC's EDL.

[dteirney]

The problem won't be fixed until XBMC's EDL methods properly handle MPEG2-TS standard.

Just use an EDL format that uses timings rather than frame marker numbers. Oh, that's right MythTV doesn't calculate those. Have you raised an enhancement request to MythTV to put the start and end times in the database as well and expose them over the Myth Protocol? If that can be done on the MythTV side XBMC doesn't need to do anything.

As I've already stated half a dozen times, counting frames doesn't solve the problem either as seeking in ffmpeg is time based. If frame counting was added to dvdplayer in XBMC the start of the commercial break could skipped at the the right time and it could guess at the end time based on the current frame rate. This would at least get closer to the correct time region, and would prevent the start time of future commercial skips getting progressively worse.

So, if you want this to happen, see if you could figure out how to count which frame number playback is at. Not sure how that might be done without spending time in the code. In theory it sounds plausibly possible. If someone can figure that out I could look at what changes would be needed to the EDL data storage and auto skip code to use the frame number rather than calculating times from frame numbers when the EDL is loaded.

[erittaf]

Thanks for the replies guys, all of that I already know... The "fix" in my post above is only an option to prevent xbmc from autoskipping commercials which gets annoying if they are in the wrong spot. At the moment I have a couple of launchers for xbmc that copy different advancedsettings.xml files to the userdata folder, one that has that "fix" in it to prevent commercial skipping and one that has a normal file to allow commercial skipping. Anyway, it'd be great if xbmc could get fixed, I'd try myself but I know nothing about the language it's written in. I may try raising a flag over at myth if I have time.

~E

[outleradam]

I've mailed the good ol' boys at FFMPEG and subscribed to the mailing list.
and
I've started a topic to gain more information at mythtvtalk.com... rather then just put in a trac ticket and let it die. http://www.mythtvtalk.com/possilbe-fix-v...#post55492

I will wait for input from that thread before I go starting a trac ticket.

[outleradam]

[b]dteirney, [/b]have you considered starting the trac ticket and posting it here? Speaking l33t C developer terms to another l33t C developer would probly be more effective then me with my mixed and minimal skillset trying to explain what would be best for the XBMC project and/or other applications. I mean, you've written APIs... I'm a API user.

[dteirney]

Just use an EDL format that uses timings rather than frame marker numbers. Oh, that's right MythTV doesn't calculate those. Have you raised an enhancement request to MythTV to put the start and end times in the database as well and expose them over the Myth Protocol? If that can be done on the MythTV side XBMC doesn't need to do anything.

As I've already stated half a dozen times, counting frames doesn't solve the problem either as seeking in ffmpeg is time based. If frame counting was added to dvdplayer in XBMC the start of the commercial break could skipped at the the right time and it could guess at the end time based on the current frame rate. This would at least get closer to the correct time region, and would prevent the start time of future commercial skips getting progressively worse.

So, if you want this to happen, see if you could figure out how to count which frame number playback is at. Not sure how that might be done without spending time in the code. In theory it sounds plausibly possible. If someone can figure that out I could look at what changes would be needed to the EDL data storage and auto skip code to use the frame number rather than calculating times from frame numbers when the EDL is loaded.

I started looking at this, but I don't think there is anyway to do the frame counting robustly. As soon as a seek is done in the file, the updated frame count would have to be guessed based on the current frame rate and the seek duration. If this skips over or into an area of the file with a variable frame rate then the frame counts are going to be immediately wrong. Fast forward or rewind would be a nightmare to account for.

Until dvdplayer in XBMC can support frame based seeking I don't think there is much that can be done to accommodate this problem in a robust manner.