Multi-m2ts BD playback/process issues discussion

[SoniG]

OK so this thread has been created to discuss about Multi-m2ts movies process and playback issues we could encounter after a rebuilding/remux/reencode or whatever.

I will talk about my own experience, issue I encounter, followed by some other users. I call of what these kind of BD are : Multi Versions main movie BD, Series BD or whatever. They are in fact structured with multiple m2ts part recognized and played thanks to real and virtual mpls playlists that indicate the player the good m2ts sequence of the right movie version that's supposed to be played seamlessly. Originals seems to play pretty well, unfortunately, reencoded/rebuilded BD don't. We mostly encounter slight frames freeze at the end of each m2ts before junctions, and/or image jumps of few frames in the begining of each m2ts junction. I first thanks again jdobbs for his BDRebuilder development, that is just irreplaceable, and that's why I would like to find a fix for it. I thank also Pelican9 for his very useful tool that allowed me to edit some clpi things to see if it could fix something, you will see the result right after. So I will try to be the fastest and the most succinct possible about what I discovered and what I'm doing to attempt to get better results with these BD. So nothing is better to give a concret exemple and work with it :

Process softwares used :
jdobbs's BD Rebuilder beta 0.33.0.6 : http://forum.doom9.org/showthread.php?t=143716
Pelican9's BDedit beta 0.34b : http://forum.doom9.org/showthread.php?t=125903
Smlabs's TSMuxer 1.10.6 : http://www.smlabs.net
Clown BD 0.76 + eac3to v3.18 : http://www.clownbd.com
x264 : 0.94.1563 fbcc1ec : http://x264.nl
Haali Media Splitter 1.9.42.1 : http://haali.su/mkv
ffdshow tryouts revision 3326 : http://sourceforge.net/projects/ffdshow-tryout
Adobe After Effects CS4 : http://www.adobe.com/products/aftereffects

Playback softwares used :
Cyberlink PowerDVD Pro 10 : http://www.cyberlink.com/products/powerdvd/overview_en_US.html
Corel WinDVD Pro 2010 : http://www.corel.com
Arcsoft TotalMedia Theatre 3 Platinum : http://www.arcsoft.com/en-us/software_title.asp?ProductCode=TMT3P


BD TESTED AND PROCESSED : LEON, THE PROFESSIONAL : 2 main movie versions (theatrical & extended), 2 main virtual mpls playlists for each version, 16 real mpls playlists linking the 16 m2ts movies parts. We will work with the theatrical version : 00001.mpls that is structured like this :

THEATRICAL MOVIE VERSION BD STRUCTURE :
http://lab.indof.com/tests/multim2tsbdr/LeonMpls01_Diagram.jpg


As we know we have an issue on process, I will begin to make some tests in touching the Delta values you can find on the clpi files, that contains following parts and seamless/following playback informations that should be used by BD Players with this kind of playlist.


ORIGINAL BD PLAYBACK, with or without ATC_Delta_entries data
http://lab.indof.com/tests/multim2tsbdr/PlaybackOriginal.jpg
- As we can see Delta datas has no influence on the process and I will stop testing it. I would add that I already tested this a bit with some reencode/re-authoring without it changed anything. However it only concerns software players here, and maybe other players would use these values. These datas has not been developed and integrated in BD structures for nothing, and should be supported by any process/re-authoring softwares to keep the best compliant process possible.

- TMT3 have a global issue with junctions playback. I first thought it was OK, but in fact it is not. I posted the issue on the Arcsoft support forum. TMT3 playback will be removed from the following tests.

Here is now the summarize of the playback tests I did, in changing step by step the process in attempt to have a good result :

PROCESSED BD PLAYBACK
http://lab.indof.com/tests/multim2tsbdr/PlaybackProcessed.jpg
- NO ENCODE : Demuxing with TSMuxer can cause an issue because of his present poor interleaving support, particularly with Video+DTS tracks, it seems some sync corrections are necessary and TSMuxer don't bother them. However, it don't stutter all the time and some BD work well, so it's difficult to have a final advise. According to crl2007 (http://forum.doom9.org/showthread.php?t=150511), this issue do exist and I would today join up with his opinion. However again, as a BDRebuilder user, I'm personally more interested by a ReEncode process, and this one works pretty differently.
- REENCODE : Avisynth or directshow seems to be the cause of the resulting stuttering frames, and we will debug this to determine what it's all about.


VISUAL PROCESS DEBUGING
http://lab.indof.com/tests/multim2tsbdr/VisualDebuging_Icon.gif (http://lab.indof.com/tests/multim2tsbdr/VisualDebuging.gif)
(click to enlarge)

That's an interesting result :
Original = OK : 00:03:02:765 TC length = 4382 frames
BD Rebuilder = M2TS --> AVS (with 'framecount 4382') --> x264 = MISMATCH : 4381 frames (1 frame missing) with 3 last images duplicated
TSMuxer --> .264 --> x264 --> TSMuxer = OK : 4382 frames

And here it seems to be our stutter issue. We had now to try to find from where the bug really comes from :

DIG OUT THE BUG
http://lab.indof.com/tests/multim2tsbdr/x264_Encode.gif

OK so I think the result speaks for itself. To resume, when playing the M2TS with Haali+ffdshow it misses about 2 or 3 images at the end. So while x264 is encoding with a specific number of frames to accomplish, like here : 4382, it encodes the frames ffdshow feed him until 4379 and duplicate this last frame twice or 3 times to match his frame number target. That's what generates the end stutter that in fact is not a stutter playback behavior but well real images that are duplicated at the end of each reencoded parts. And in fact it comes from Haali, but sshhht... It's a secret!

TEMPORARY ISSUE WORKAROUND
So here is the solution I'm applying to make work these BD :
- Rebuild all the BD with BD Rebuilder with tracks, reencode, final size needed to 'BDMini' folder (or whatever name you want)
- Rebuild the same project but with 'FORCE_NOENCODE=1' on the settings to 'BD-' folder (or whatever name you want too)
- Create a big .cmd* file with all the necessary demuxed.264 reencode commands from the BD- WORKFILES folder (so in bypassing Avisynth+Haali+ffdshow) to already reencoded.264 files of the BDMini folder (so in fact it reencodes and replaces them automatically)
- Just click the Rebuild button again from the first project, BD Rebuilder will remux and recreate the BD structure with all the new fixed/reencoded files.

*You need to specify the fps and the good bitrate. fps would normally be --fps 24000/1001. The good bitrate is the one that BD Rebuilder had already calculated, and can be found on the .INF file of the BDMini folder (RATE=xxx). We could add --frames 'FramesNumbers' too if needed.

Of course, this is not the solution. It's just here to explain what I do and to begin to think about an official and compliant process. And we would maybe first discuss about this strange haali/ffdshow behavior, to know if it's really a bug or another indirectly bad behavior or anything else?

In any case, I hope you found this interesting, apologize me for my risky English sometimes and I thank you to have read this until the end.


UPDATE : Issue fixed by jdobbs on BD Rebuilder since the 0.34.0.1 version.

[crl2007]

I have read all your post and it is interesting. You came to see for yourself most of my conclusion ( after you argued with me for them :P ). For frame accuracy you should first index the movie with dgavcdecnv (http://neuron2.net/dgavcdecnv/dgavcdecnv.html) ( it incorporates dgindexnv, dgavcdecnv and dgvc1decnv and works even if you don't have a nvidia video card ) and save the *.dga project file. You feed that *.dga file in your avs script instead of the *.m2ts file.

dgsource("path\*.dga")
converttoyv12()

I found this to be more frame accurate.

[SoniG]

You came to see for yourself most of my conclusion ( after you argued with me for them :PYeah but unfortunately I still couldn't really show eac3To do a better job than TSMuxer, as all the BD I tested right now work well with TSMuxer, LEON included. However I noticed some sync corrections eac3To does but TSMuxer doesn't. So who knows! For frame accuracy you should first index the movie with dgavcdecnv (http://neuron2.net/dgavcdecnv/dgavcdecnv.html) ( it incorporates dgindexnv, dgavcdecnv and dgvc1decnv and works even if you don't have a nvidia video card ) and save the *.dga project file. You feed that *.dga file in your avs script instead of the *.m2ts file.
dgsource("path\*.dga")
converttoyv12()I found this to be more frame accurate.Demux the video track and feed it to x264 shouldn't be even more accurate than an indexation from the m2ts? However I will give it a try and tell you my result. x264 have also an indexer but seems not good.

[Guest]

For frame accuracy you should first index the movie with dgavcdecnv (http://neuron2.net/dgavcdecnv/dgavcdecnv.html) ( it incorporates dgindexnv, dgavcdecnv and dgvc1decnv and works even if you don't have a nvidia video card ) and save the *.dga project file. You feed that *.dga file in your avs script instead of the *.m2ts file.

dgsource("path\*.dga")
converttoyv12()

I found this to be more frame accurate. That is not a good idea as DGIndexNV and DGSource expect different versions of the index file. It's totally unsupported. Anyway, you are pointing to obsolete versions of my NV tools. I have now removed them from my web site.

[crl2007]

That's where I've always took them. Now I see that you changed location.

And that script always opened the files and resulted in successfull encodes.

NVbeta3 is the latest build ?

l.e. I see that in your manual, you have put an avs template that looks like this:

loadplugin("...\DGDecodeNV.dll")
loadplugin("...\Decomb.dll")
dgsource("__vid__")
fielddeinterlace()

Normally, in my avisynth plugin folder I have the latest dll of DGDecodeNV. And if you have the plugins in the avisynth plugin folder, there is no need to call them.

Anyway, the situation remains the same for this test, just that SoniG has to take the latest NVbeta3.

[Guest]

Gosh, is it so hard to simply go to my web site and see it?

The latest version is DGDecNV 2007.

[deank]

@SoniG: Thank you for your complete post.

Can you analyze the last GOP of the M2TS file. Is it closed or part of it / some of the frames are in the next (seamlessly connected) M2TS?

[crl2007]

Gosh, is it so hard to simply go to my web site and see it?

The latest version is DGDecNV 2007.


Yeah, I've seen it after that. It had so many name changes, that it is hard to keep track.

l.e. The code from earlier modifies to: dgsource("path\*.dgi")
converttoyv12()

[Guest]

It had so many name changes, that it is hard to keep track. I suppose some people find it really hard to visit a web page or follow threads at Doom9.

l.e. The code from earlier modifies to: dgsource("path\*.dgi")
converttoyv12() That will require a supported NV card and license.

[crl2007]

I do not want to be rude, but when a program has the same name over years ( like every software on the planet ), it is just easier for me to search google for a version update. I'm not the kind to have 1000 bookmarks for every page on the planet.

As for the nv card and license, I know. But who wants to use the program can donate. I'm pro supporting developers. I did not tell him to cheat you in any manner. From your tone ( how you wrote it ) it seemed that I did something wrong when recommending this software. If I misunderstood, then I'm sorry.

The other version worked with other cards if you had the CUDA dll, that's why I previous have said that you do not need a NV card.

[Guest]

The other version worked with other cards if you had the CUDA dll, that's why I previous have said that you do not need a NV card. You think it's possible to decode with nvcuvid.dll but without a supported NV card present? You are making no sense to me.

If you were suggesting to index with DGAVCIndexNV (old NV version) and then serve video with DGAVCDecode (non-NV version), it makes no sense due to the different index files. You could simply index with DGAVCIndex (non-NV version).

[jdobbs]

@SoniG

Interesting analysis. Thanks.

I'm not sure I understand. Are you reencoding a second time using the built-in decoding capability of X264 (FFMS2)? If so, that works for most sources -- but unfortunately FFMS2 has issues with interlaced sources. I already have code built into BD-RB that can use FFMS2 as the source (rather than FFDSHOW/HAALI). I could probably use that decoder for all except interlaced sources (which would rarely if ever be a multipart film) and solve this inherently in BD-RB.

The thing that confuses me is why I haven't been seeing this issue on my player... if I follow your post correctly it should happen on all players (since frames are duplicating). It makes me think that it may be something introduced recently by HAALI or FFDSHOW? I'll do some investigating.

[crl2007]

When I had an ATI HD 2900 XT, it worked. But, for the last 2 years I have NV. I don't really remember what "hoops" I had to jump to make it work.

But maybe would be best to take the non NV version if he has not a NV card.

[SoniG]

jdobbs : Yeah precisely, I wonder if others have the same bug than me, even if I'm pretty sure there is, as I can fix it in bypassing Haali. However it would be pretty interesting other guys would test and confirm all of this. It's easy to test with mediaplayer classic, in using frame by frame keys. With an external player you had to plug your bionicle eyes and be ready at m2ts junctions. However with PowerDVD the difference between a bugged and a fixed BD is pretty clear!
About FFMS2, I don't really think it is used. I even get 'ffms [error]: could not create index', but as I use the raw demuxed video track, there shouldn't need any index. However resolution flag should be used as maybe other flags I'm not aware. Here is my present cmd line for fast testing : "C:\BD_Rebuilder\tools\x264.exe" "D:\somewhere\BD-_Leon\WORKFILES\05006.track_4113.264" --preset superfast --fps 24000/1001 --b-pyramid none --weightp 0 --qpmin=0 --bitrate 7000 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 14500 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 17500 --threads 8 --slices 4 --thread-input --output "D:\somewhere\BDMini_Leon\WORKFILES\VID_05006.AVS.264"
Hope you will find a way to implement all of this easily.

crl2007 : I have a NVidia card and will give it a try, however, as BD Rebuilder already use demux functions to sort, blank and calculate tracks things, I don't think any external index process is needed.

deank : No all you see here come from the 05006.m2ts file of the BD. No next m2ts frame, to stay clear. About GOP of M2TS, I don't really know how to analyse it. I'm a post-production professional, but about all these advanced encoding and analyse processes, I'm a pretty n00b! :)

[LowDead]

I have seen this bug before, both on my PS3 and Sony SAP. For example Watchmen. No stuttering but it looks like it freeze up for like a micro second or so and then continue on. Not so it bacome annoying but as much to notice it.

[jdobbs]

I have seen this bug before, both on my PS3 and Sony SAP. For example Watchmen. No stuttering but it looks like it freeze up for like a micro second or so and then continue on. Not so it bacome annoying but as much to notice it. Good to know.

[SoniG]

I have seen this bug before, both on my PS3 and Sony SAP. For example Watchmen. No stuttering but it looks like it freeze up for like a micro second or so and then continue on. Not so it bacome annoying but as much to notice it.Yeah, that is exactly what is exposed here.

[deank]

Probably the duration of the freeze of just about 82 to 125ms is not so easily noticed and probably not a lot of people can actually see it. :)

[crl2007]

We, who can see them, are cursed. Because they annoy us. :) Ignorance is bliss.

ONTOPIC: I think that if more users with standalone players that have stutters will come forward and test alongside us, the job would be done more easily.

@SoniG Yes, BD-RB calculates all of that, but it does not do it with that software. Worths a try. I'm eager to hear your conclusions.

[jdobbs]

We, who can see them, are cursed. Because they annoy us. :) Ignorance is bliss.

ONTOPIC: I think that if more users with standalone players that have stutters will come forward and test alongside us, the job would be done more easily.

@SoniG Yes, BD-RB calculates all of that, but it does not do it with that software. Worths a try. I'm eager to hear your conclusions. I already fixed it. The next release will use the FFMS decoding of X264 for seamless branched (or multi-angle) sources (as long as you aren't resizing -- as that requires AVISYNTH).

[jdobbs]

@SoniG: Thank you for your complete post.

Can you analyze the last GOP of the M2TS file. Is it closed or part of it / some of the frames are in the next (seamlessly connected) M2TS? I don't think it can be. By definition a seamless branched stream has multiple directions it can go. So an open GOP couldn't have consistent forward/reverse referencing unless the first GOP of all referenced M2TS files was identical, which isn't likely. It would also make the individual M2TS files non-integral. Of course stranger things have happened in the BD world, I guess.

[SoniG]

I already fixed it. The next release will use the FFMS decoding of X264 for seamless branched (or multi-angle) sources (as long as you aren't resizing -- as that requires AVISYNTH).Good news jdobbs!

crl2007 : I can't use the software, it asks me a license file. And if you can tell me what it supposes to give more than FFMS. It should deserve to be implemented if it really worth to.

[jdobbs]

Good news jdobbs!

crl2007 : I can't use the software, it asks me a license file. And if you can tell me what it supposes to give more than FFMS. It should deserve to be implemented if it really worth to. I posted an update in the BD-RB beta test thread.

[Guest]

crl2007 : I can't use the software, it asks me a license file. And if you can tell me what it supposes to give more than FFMS. If you don't know then you don't need it. Don't worry; be happy!

[SoniG]

If you don't know then you don't need it. Don't worry; be happy!Well if you could give more informations, I promise I will not enter in depression!

I posted an update in the BD-RB beta test thread.Thanks jdobbs, I will check it right now!

[SoniG]

jdobbs : Great jdobbs, we are nearly done! All the movie is ok as shown here : http://lab.indof.fr/tests/multim2tsbdr/BDRebuilder03307_ReEncode_2.5fps_icon.gif (http://lab.indof.fr/tests/multim2tsbdr/BDRebuilder03307_ReEncode_2.5fps.gif)
Except one part : 05002.m2ts that gives this strange indexing and result behavior at the beginning, with sound out of sync along the part : http://lab.indof.fr/tests/multim2tsbdr/indexbug_icon.jpg (http://lab.indof.fr/tests/multim2tsbdr/indexbug.jpg) http://lab.indof.fr/tests/multim2tsbdr/BDRebuilder03307_SomePartsBug_icon.gif (http://lab.indof.fr/tests/multim2tsbdr/BDRebuilder03307_SomePartsBug.gif)

If it could help, I can tell you it's the biggest part of the movie : 43mn50 and the one expanded by default in the BDR Stream tab. Without this, all seems perfect!

[jdobbs]

jdobbs : Great jdobbs, we are nearly done! All the movie is ok as shown here : http://lab.indof.fr/tests/multim2tsbdr/BDRebuilder03307_ReEncode_2.5fps_icon.gif (http://lab.indof.fr/tests/multim2tsbdr/BDRebuilder03307_ReEncode_2.5fps.gif)
Except one part : 05002.m2ts that gives this strange indexing and result behavior at the beginning, with sound out of sync along the part : http://lab.indof.fr/tests/multim2tsbdr/indexbug_icon.jpg (http://lab.indof.fr/tests/multim2tsbdr/indexbug.jpg) http://lab.indof.fr/tests/multim2tsbdr/BDRebuilder03307_SomePartsBug_icon.gif (http://lab.indof.fr/tests/multim2tsbdr/BDRebuilder03307_SomePartsBug.gif)

If it could help, I can tell you it's the biggest part of the movie : 43mn50 and the one expanded by default in the BDR Stream tab. Without this, all seems perfect! That looks a lot like an error in FFMS -- I've gotten them a lot before with the FFMS2 AVISYNTH plugin (which was why I dumped it), but hadn't seen it before when used through X264. Unfortunately, because the film could be VC-1 or MPEG-2 in addition to AVC, you have to use FFMS. The other possibility is that the source is corrupted. Have you done any processing on that file that would make it different from the original?

What film is this? I'd like to pick it up and give it a try. I did extensive testing with two other seamlessly branched films and didn't see any issues like this. You didn't see this when you reencoded by hand?

[SoniG]

Still the same : LEON, THE PROFESSIONAL Theatrical and Extended Versions (http://anonym.to/?http://www.blu-ray.com/movies/Leon-The-Professional-Blu-ray/6964/). All the movie parts are in AVC with some MPEG-2 bonuses.

[jdobbs]

Still the same : LEON, THE PROFESSIONAL Theatrical and Extended Versions (http://anonym.to/?http://www.blu-ray.com/movies/Leon-The-Professional-Blu-ray/6964/). All the movie parts are in AVC with some MPEG-2 bonuses. Just out of curiosity, did you try any other (newer) builds of HAALI to see if the issue was still there?

[SoniG]

jdobbs :Yeah I already tried the last version 1.10.120.15 and even between ones and it gives the same result! Is there only Haali as a useable splitter? Could you just demux and encode from the raw video track? I think it gives the same result without the need of an indexation, and without this bug!

[jdobbs]

jdobbs :Yeah I already tried the last version 1.10.120.15 and even between ones and it gives the same result! Is there only Haali as a useable splitter? Could you just demux and encode from the raw video track? I think it gives the same result without the need of an indexation, and without this bug! You can do that for AVC, but you need FFMS for the other two, the results may be different without the M2TS wrapper, though. I've created a version that uses the demuxed output -- I'll PM you with a link so you can try it.

[SoniG]

Issue fixed on BD Rebuilder since version 0.34.0.1 thanks to jdobbs.

[jdobbs]

Issue fixed on BD Rebuilder since version 0.33.0.9 thanks to jdobbs. I've made a couple more changes for 0.34.01. It seems that using FFMS for demuxing on some random files caused X264 to get really confused about bitrate and create blocky output (e.g. Sherlock Holmes). But it went away when I switched to LAVF demuxing. I was happy to find that LAVF works with .VC1 and .MPV files as well as .264.

[SoniG]

OK, I updated the thread to favour this version and I can tell you that the STARGATE (rebel) BD also works now, certainly thanks to this new LAVF process! I suppose all BD can be processed now! I wondered if some stutters could come from this thing I saw on Mediainfo (also on Stargate), the Reframes=3 and x264 ref=4 from the same m2ts, that I don't really understand, but finally it was not this.