[RESOLVED] Problematic stream

Support forum for DGDecNV
AJR
Distinguished Member
Distinguished Member
Posts: 106
Joined: Mon Jan 06, 2014 11:40 am

[RESOLVED] Problematic stream

Post by AJR » Tue Mar 07, 2017 9:08 am

Hello,

I have one h264 TS stream which throw me some errors using DGDecNV. VideoReDo has no problem with this stream. Can you please check it?
I have upload two files and send you download link to PM:

1) small part of original TS - video.ts, it just show me first error window. No matter what I hit if YES or NO, it wont open the stream. I can play this file with MPC-HC without problem.
2) much bigger part of original TS demuxed by VideoReDo to *.h264, with this file DGDecNV show another error. I can play also this file with MPC-HC without problem.

Please try both files and let me know if found anything for fix or do you think the original TS file is just corrupted? If so why VideoReDo has no problem with it? ;)

I have tested it with latest 2053 and also some older versions 2052-2050. It doesnt work with any version. Other streams work fine, so I guess my problem is not related to HW(mobile GTX850) or license issue.

Thank you
Attachments
snap000088.png
2)
snap000088.png (29.48 KiB) Viewed 1063 times
snap000087.png
1)
snap000087.png (26.95 KiB) Viewed 1063 times

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Problematic stream

Post by admin » Tue Mar 07, 2017 11:15 am

Downloading to investigate...

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Problematic stream

Post by admin » Tue Mar 07, 2017 12:31 pm

I need to get the full original TS from which the h264 was demuxed by VideoRedo. CUVID does not like the first SPS in the demuxed ES. H.264 Video ES Viewer also sees problems with the SPS. The ES also fails an Assert() in the reference decoder, so there may be something fishy with it. I want to see if the original TS is also affected before digging further. Yes, I realize that you say it plays fine in MPC-HC, but I not have source code for the decoder being used.

While I wait for that I'll look into the audio mismatch seen with video.ts.

AJR
Distinguished Member
Distinguished Member
Posts: 106
Joined: Mon Jan 06, 2014 11:40 am

Re: Problematic stream

Post by AJR » Tue Mar 07, 2017 3:35 pm

Ok, I will upload original TS file. Give me a time ;)

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Problematic stream

Post by admin » Tue Mar 07, 2017 4:33 pm

Take your time. I've progressed somewhat. It runs OK with the nVidia decode sample and an old decoder I made as a proof of concept for DGDecNV. So something appears to be wrong in my backyard. I'm homing in on it.

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Problematic stream

Post by admin » Tue Mar 07, 2017 6:26 pm

It's a bug in my NALU parser. Some strange combination in that file is getting her confused. Should be fixable without too much trouble.

AJR
Distinguished Member
Distinguished Member
Posts: 106
Joined: Mon Jan 06, 2014 11:40 am

Re: Problematic stream

Post by AJR » Tue Mar 07, 2017 6:32 pm

Good news, thank you for your time!

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Problematic stream

Post by admin » Tue Mar 07, 2017 8:59 pm

False alarm. It wasn't the NALU parser. Still searching... This is a tough one. :facepalm:

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Problematic stream

Post by admin » Tue Mar 07, 2017 9:14 pm

If I open your original TS and hit cancel on the audio popup then that plays fine. Then I demux it with DGIndexNV and the resulting ES plays fine. So it is looking like something strange from the VideoRedo demuxing. I do see some custom SEIs in the demuxed file so maybe it is related to that.

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Problematic stream

Post by admin » Tue Mar 07, 2017 10:28 pm

Ha, I got it! It was the VideoRedo SEI after all. It's legal but it was doing something I never anticipated. I worked for 10 solid hours to find this (with a half hour beer break).

Technical details: When the semantic contents of a NALU contain 00 00 01 it gets mapped to 00 00 03 01 to prevent start code emulation. When I process SEI's I remove the 03's so that my parser can work correctly on the NALU. But when I pass the NALU to the CUVID decoder I have to leave the 03's in there (he also doesn't want to hit emulated start codes). I was doing this for all NALU types except for...wait for it...SEIs. Now this is the first time I have ever encountered an SEI containing an escaped start code like that. I added this handling for SEIs and everything works fine with video2.h264.

I also fixed the audio mismatch problem for video.ts. DVB subtitling was being detected as AC3 audio.

Tomorrow I'll slipstream these fixes and my new CUDA filter DGSharpen.

Post Reply