Timecode issue with rendering in MPEG-2

[BadgerKing]

Ok, I used Mkvmergegui and opened it in MPC - there is no timecode problem.

[mirkosp]

Then my assumption is that during the encode, the video and audio encoding went fine, but then something (don't know exactly what) happened with the muxing and thus some information was missing. Perhaps trying to run the encode once again would make the new file work fine?

[BadgerKing]

I've done the encode multiple times with both Premiere Pro and TMPGEnc and it happens every time. I downloaded the Procoder 2 demo and gave that a shot, and it didn't give me any problems (btw, does it matter if it's a .m2p or .m2v file instead of just .mpeg in that case?).

I've also tried rendering a different video clip from Premiere Pro and there wasn't an issue either.


I'm stumped. I've exported from Premiere Pro with the same PAR, resolution, and field type - and I tried encoding in TMPGEnc with both lagarith and as an uncompressed avi. I guess it's just something with my clips or the project itself. :/

[mirkosp]

I'll have to summon somebody better than me, as my knowledge when it comes to containers is rather limited.
I think Mister Hatt has been doing stuff regarding H.222 lately, so he might be of help here.

[BadgerKing]

Alright - thank you for your help.

[Mister Hatt]

MPEG-PS and PCR issues I think. I'm more familiar with MPEG-TS though, and it continues to astound me that AMV coordinators don't refuse anything that isn't MKV to be honest.

Is there any reason you can't just submit it in a different format? Either MPEG-TS or MKV should work fine. In regards to your actual problem, can you try in TMPGEnc with a higher frequency of I-frames? What is probably happening is that PCR packets (timecode info based off a core system clock) are not frequent enough in your stream so dshow is having issues with frame accurate seeking. lavf is more forgiving with such things and will scan or index the file if it cannot find a PCR right away, making it slower but more accurate. Of course this isn't an issue in modern PC hardware but dshow isn't exactly a recent thing.

If you MUST have mpg format, you can try remuxing with avconv and it may fix it or re-index it for you, worth a try I think. MPEG-PS is meant to have it's own timecode setup but because it's H.222 it still does this via PCR with a fixed base clock instead of the sexy way m2ts does it with dedicated timecodes. Still worth trying TMPGEnc with more I-frames or other similar flags tweaked to provide more seek info for the GOP. Maybe use avprobe to check how many I-frames are in your content between different encoders even as it could just be you don't have enough GOPs rather than the PCR being infrequent. So a few options on how to progress there.

glhf~

[NeoQuixotic]

I've had a similar issue. When playing back a .m2v file I would have the playback time in MPC-HC display shorter than the actual time of the video. However, when the seek bar reached the end it would continue to play the rest of the video. I just did a reformat last week and tried playing a .m2v I encoded using HC Encoder and the length was correct. I have MPC-HC forcing LAV Video/Audio decoder. So I checked what filters were being used and noticed "MainConcept MPEG Demultiplexer" was being used when playing the .m2v file. So I blocked the MainConcept filter and tried playing it again. This time the incorrect time issue occured and "LAV Splitter" took the place of the MainConcept filter.

To test things even further I opened up Vegas and encoded a 6 minute video to an .m2v elementary stream and also to a .mpg file. With "LAV Splitter" it showed the incorrect time again on the .m2v, but was correct with the .mpg file. So I blocked "LAV Splitter" and "MPEG-2 Splitter" took its place with the same results. My guess is it's just whatever is trying to playback(split) the file. Maybe when you installed the ProCoder 2 demo it replaced/preferred some filters it installed. I think something like GraphStudio would be useful for troubleshooting. The "MainConcept MPEG Demultiplexer" (mc_demux_mp2_ds.ax) that is currently registered for me came from a Cineform NeoScene install I use. And it looks like Encore and other Adobe Media apps have their own version of the filter in their program directory they use, but don't register with the system. Since once I used that file in Encore and similar Adobe apps I had no issues.

For me my problem is whatever is splitting the file, but maybe it's different for you. Any chance you could upload the problem file anywhere?

[Mister Hatt]

Interesting and something I didn't really think of. Although, it works in VLC apparently and that uses lavf, just like LAV filters and ffdshow-tryouts do. What's interesting is that it seems to only break under dshow, which would imply old versions of lavf compared to what VLC packages. I wonder how ffms2 handles it in avisynth.

The problem is obviously in the demuxer either way, although it is most likely caused by how the encoder placed GOPs in the initial stream to mux which is why the encoder changes the behaviour.

[BadgerKing]

MPEG-PS and PCR issues I think. I'm more familiar with MPEG-TS though, and it continues to astound me that AMV coordinators don't refuse anything that isn't MKV to be honest.

Is there any reason you can't just submit it in a different format? Either MPEG-TS or MKV should work fine. In regards to your actual problem, can you try in TMPGEnc with a higher frequency of I-frames? What is probably happening is that PCR packets (timecode info based off a core system clock) are not frequent enough in your stream so dshow is having issues with frame accurate seeking. lavf is more forgiving with such things and will scan or index the file if it cannot find a PCR right away, making it slower but more accurate. Of course this isn't an issue in modern PC hardware but dshow isn't exactly a recent thing.

If you MUST have mpg format, you can try remuxing with avconv and it may fix it or re-index it for you, worth a try I think. MPEG-PS is meant to have it's own timecode setup but because it's H.222 it still does this via PCR with a fixed base clock instead of the sexy way m2ts does it with dedicated timecodes. Still worth trying TMPGEnc with more I-frames or other similar flags tweaked to provide more seek info for the GOP. Maybe use avprobe to check how many I-frames are in your content between different encoders even as it could just be you don't have enough GOPs rather than the PCR being infrequent. So a few options on how to progress there.

glhf~

The AMV coordinator said she could accept other formats, but she was able to re-convert the one I had already sent in and was able to fix the issue (hopefully). Once I get home I'll try what you suggested in TMPGEnc and avconv. I'm just hoping that this isn't something that will happen every time I might render an mpeg-2, regardless of the file, and that it's just something weird going on with the project or source files.

I'm also going to try opening the project on my work computer with an older version of Premiere Pro to see if it might be something that is due to CS5.5 or some other issue with my computer, as well as try encoding it with TMPGEnc on the work comp.

For me my problem is whatever is splitting the file, but maybe it's different for you. Any chance you could upload the problem file anywhere?

Once I've tried everything else and when I re-encode for online submission, I'll upload the original source that is having the issue for download. The only thing that is really bothering me is that it's not occurring on my work computer at all when playing in WMP or MPC (another reason why I'm going to try exporting the project from an older Premiere Pro version to see if it's just something going on with my computer at home).

[BadgerKing]

Two questions:
1) Where do I increase the I-frames in TMPGEnc? Is there a certain number I should be striving for in order to see better results?
2) Under the Advanced Setting it has Inverse Telecline checked, which says that it'll convert it to 24fps - does this conflict with keeping my framerate at 29.97 instead of "23.976 fps (internally 29.97 fps)" ? Since the convention submission guide says if it's at 29.97 fps to keep it at that and choose 'Interlace' for the Encode mode.