Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th February 2012, 13:20   #14661  |  Link
ipanema
Registered User
 
Join Date: Apr 2009
Posts: 93
Quote:
Originally Posted by haruhiko_yamagata View Post
@ipanema,
It has been fixed at rev 4302. Please try the latest build.
That was quick - thanks. I've just tried 4305 and it does seem to be fixed now. Great work.

A side issue, but I noticed that the decoder still does not output the leading B frames which other decoders manage to do. It's a bug report from 2009

http://sourceforge.net/tracker/index...41&atid=867360

For example, my FILE3 begins with the following input start timestamps

7770333
7103000 > B frame
7436666 > B frame
8771333
8104000
8437666
9772333
9105000
9438666

and Microsoft and Mainconcept decoders both output all the frames

7103000 > B frame
7436666 > B frame
7770333
8104000
8437666
8771333
9105000
9438666
9772333

but the ffdshow decoder outputs

7770333
8104000
8437666
8771333
9105000
9438666
9772333

note the missing B frames at the beginning.
ipanema is offline   Reply With Quote
Old 6th February 2012, 13:26   #14662  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,962
Thats quite normal, ffdshow will try to not output frames that show corruption, and a B frame needs more then the first I frame to be decodable without corruption.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 6th February 2012, 13:34   #14663  |  Link
ipanema
Registered User
 
Join Date: Apr 2009
Posts: 93
OK, but the leading B frames output by the Microsoft and Mainconcept decoders never show any corruption.
ipanema is offline   Reply With Quote
Old 6th February 2012, 15:02   #14664  |  Link
Blight
Software Developer
 
Blight's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 992
Hi,
I have a serious issue with recent builds (tested builds upto 4303) of ffdshow's audio decoder when the "Connect as PCM first" setting is disabled.
For some reason, when playing certain audio files (tested with AC3/DTS), the audio decoder exposes two media types.
One with major type "Audio" (and DTS/AC3 subtype) and a second with major type "stream" and sub-type "none":


The problem is, my DSP filter is first presented with the "Stream" media type first and when it's rejected with "VFW_E_TYPE_NOT_ACCEPTED", the second media type (major type audio) isn't presented to my DSP filter at all.
If I enable "Connect as PCM first" or disable pass-through to S/PDIF, the problem disappears.

My question is,
Why is there a second media type with these values?
If it's an important feature for some conditions, can you make it optional and possibly default it to off?
__________________
Yaron Gur
Zoom Player . Lead Developer

Last edited by Blight; 6th February 2012 at 15:04.
Blight is offline   Reply With Quote
Old 6th February 2012, 16:22   #14665  |  Link
kc7bfi
Registered User
 
Join Date: Nov 2010
Location: Chesapeake, VA USA
Posts: 38
Quote:
Originally Posted by kc7bfi View Post
I have confirmed that the problem with the Optelecom H.264 video was created somewhere between version 4174 and 4194. Version 4174 plays the video fine but 4194 seems to only be playing I-frames. Any ideas what may have changed in those versions? If there are any intermediate Windows 64 bit installs I can also test them to try and narrow down the exact revision that caused the problem. Just let me know if they are available. Any help in resolving this issue would be greatly appreciated. David
I have verified that this was "broke" in version 4176. Version 4175 plays the Optelecom H.264 fine but version 4176 seems to only play I-frames. Any ideas what might have been changed? I looked through the code but I am far from understanding it. Thanks, David
kc7bfi is offline   Reply With Quote
Old 6th February 2012, 19:07   #14666  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 4,669
Quote:
Originally Posted by kc7bfi View Post
I have verified that this was "broke" in version 4176. Version 4175 plays the Optelecom H.264 fine but version 4176 seems to only play I-frames. Any ideas what might have been changed? I looked through the code but I am far from understanding it. Thanks, David
I need a sample file to reproduce the problem.
clsid is offline   Reply With Quote
Old 6th February 2012, 19:07   #14667  |  Link
kc7bfi
Registered User
 
Join Date: Nov 2010
Location: Chesapeake, VA USA
Posts: 38
Quote:
Originally Posted by kc7bfi View Post
I have verified that this was "broke" in version 4176. Version 4175 plays the Optelecom H.264 fine but version 4176 seems to only play I-frames. Any ideas what might have been changed? I looked through the code but I am far from understanding it. Thanks, David
Here is the DebugView from 4175
Quote:
00000172 1.17888844 [10352] TffdshowDecVideo::Run thread=10896
00000173 1.41790235 [10352] TimgFilterOutput::process V-RAM access is Direct, t_indirect = 50000, t_direct = 50000
00000174 1.88360322 [10352] no frame!
00000175 2.71864915 [10352] no frame!
00000176 3.55155683 [10352] no frame!
00000177 4.38556004 [10352] no frame!
00000178 5.21953058 [10352] no frame!
00000179 6.05361080 [10352] no frame!
00000180 6.70131016 [10352] TffdshowDecVideo::Stop thread=8348
00000181 6.70138931 [10352] TffdshowDecVideoOutputPin::DeliverEndOfStream
00000182 6.70144272 [10352] TffdshowDecVideoOutputPin::Inactive
00000183 6.79012012 [10352] Removed from filter graph
00000184 6.79810095 [10352] TffdshowDecVideo::Destructor
00000185 6.79825163 [10352] TffdshowDecVideoOutputPin::Destructor
Here is the DebugView from 4176
Quote:
00000172 1.21519601 [1428] TffdshowDecVideo::Run thread=9688
00000173 1.33532727 [1428] Missing reference picture
00000174 1.33536828 [1428] decode_slice_header error
00000175 1.33587193 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000176 1.34136713 [1428] Frame num gap 2 0
00000177 1.34260333 [1428] Frame num gap 3 1
00000178 1.35833633 [1428] Frame num gap 4 2
00000179 1.35930073 [1428] Frame num gap 5 3
00000180 1.36132705 [1428] Frame num gap 6 4
00000181 1.36357117 [1428] Frame num gap 7 5
00000182 1.36568916 [1428] Frame num gap 8 6
00000183 1.39263272 [1428] Frame num gap 9 7
00000184 1.45666087 [1428] Frame num gap 10 8
00000185 1.46278739 [1428] Frame num gap 11 9
00000186 1.49258065 [1428] Frame num gap 12 10
00000187 1.52566409 [1428] Frame num gap 13 11
00000188 1.52720392 [1428] TimgFilterOutput::process V-RAM access is Direct, t_indirect = 50000, t_direct = 30000
00000189 1.56086862 [1428] Frame num gap 14 12
00000190 1.59262443 [1428] Frame num gap 15 13
00000191 1.62587583 [1428] Missing reference picture
00000192 1.62593484 [1428] decode_slice_header error
00000193 1.62600315 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000194 1.65942085 [1428] mmco: unref short failure
00000195 1.65982413 [1428] Missing reference picture
00000196 1.65985489 [1428] decode_slice_header error
00000197 1.65990770 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000198 1.69238532 [1428] mmco: unref short failure
00000199 1.69255745 [1428] Frame num gap 2 0
00000200 1.72563791 [1428] Frame num gap 3 1
00000201 1.72627270 [1428] Frame num gap 4 2
00000202 1.72825873 [1428] Frame num gap 5 3
00000203 1.82658899 [1428] Frame num gap 6 4
00000204 1.85965872 [1428] Frame num gap 7 5
00000205 1.89266777 [1428] Frame num gap 8 6
00000206 1.92944741 [1428] no frame!
00000207 1.99259627 [1428] Missing reference picture
00000208 1.99266315 [1428] decode_slice_header error
00000209 1.99328876 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000210 2.02658963 [1428] Frame num gap 2 0
00000211 2.05956984 [1428] Frame num gap 4 2
00000212 2.06051445 [1428] Frame num gap 5 3
00000213 2.12658978 [1428] Frame num gap 6 4
00000214 2.19343543 [1428] Frame num gap 8 6
00000215 2.22663951 [1428] Frame num gap 9 7
00000216 2.25960851 [1428] Frame num gap 10 8
00000217 2.32662439 [1428] Frame num gap 12 10
00000218 2.35958147 [1428] Frame num gap 13 11
00000219 2.39361620 [1428] Frame num gap 14 12
00000220 2.46083927 [1428] Missing reference picture
00000221 2.46089482 [1428] decode_slice_header error
00000222 2.46102023 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000223 2.49345899 [1428] mmco: unref short failure
00000224 2.49374795 [1428] Missing reference picture
00000225 2.49380755 [1428] decode_slice_header error
00000226 2.49390459 [1428] concealing 1350 DC, 1350 AC, 1350 MV errors
00000227 2.52646852 [1428] mmco: unref short failure
Both versions are playing the same video. Any ideas? David
kc7bfi is offline   Reply With Quote
Old 6th February 2012, 19:13   #14668  |  Link
kc7bfi
Registered User
 
Join Date: Nov 2010
Location: Chesapeake, VA USA
Posts: 38
Quote:
Originally Posted by clsid View Post
I need a sample file to reproduce the problem.
Here is a wireshark capture:
http://dl.dropbox.com/u/37804952/Optelecom.pcap

Here is a Matroska recording
http://dl.dropbox.com/u/37804952/Optelecom.mkv

This is a live encoder. If it would be helpful I could also put our encoder in the Internet so you could access it.

Thanks for the help. David
kc7bfi is offline   Reply With Quote
Old 7th February 2012, 11:05   #14669  |  Link
Liisachan
李姗倩 Lǐ Shān Qin
 
Liisachan's Avatar
 
Join Date: Nov 2002
Posts: 1,140
Quote:
Originally Posted by haruhiko_yamagata View Post
OK, then I'll create a new item.
Thanks! Your awesome work, especially in Subtitles, is always appreciated
Liisachan is offline   Reply With Quote
Old 7th February 2012, 13:44   #14670  |  Link
haruhiko_yamagata
Registered User
 
Join Date: Feb 2006
Location: Japan
Posts: 1,560
Quote:
Originally Posted by kc7bfi View Post
Here is a wireshark capture:
http://dl.dropbox.com/u/37804952/Optelecom.pcap

Here is a Matroska recording
http://dl.dropbox.com/u/37804952/Optelecom.mkv

This is a live encoder. If it would be helpful I could also put our encoder in the Internet so you could access it.

Thanks for the help. David
I tried the mkv file. If LAV Splitter Source is used, and the decoder is either LAV Video Decoder or ffdshow, it does not work. Microsoft DTV decoder works.
If Haali's splitter is used, it is OK. nevcairiel, if you are reading this, would you take a look?

@kc7bfi,
As the example above shows, the source/splitter filter is the key. I can't debug anything or help you unless you provide the source/splitter filter.
__________________
[ Download ffdshow | Wiki ]
haruhiko_yamagata is offline   Reply With Quote
Old 7th February 2012, 13:54   #14671  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,962
Quote:
Originally Posted by haruhiko_yamagata View Post
nevcairiel, if you are reading this, would you take a look?
That file is odd, whatever muxed it is a broken application.
It muxed an AnnexB stream into MKV, which in itself is not wrong, BUT it created MP4 style extradata. Either you mux in AnnexB mode, or in MP4 mode, combining the two is .... weird. Horrible.

I can probably fix it in the splitter, though.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 7th February 2012, 14:28   #14672  |  Link
haruhiko_yamagata
Registered User
 
Join Date: Feb 2006
Location: Japan
Posts: 1,560
Quote:
Originally Posted by nevcairiel View Post
That file is odd, whatever muxed it is a broken application.
It muxed an AnnexB stream into MKV, which in itself is not wrong, BUT it created MP4 style extradata. Either you mux in AnnexB mode, or in MP4 mode, combining the two is .... weird. Horrible.
I agree it's horrible and broken. Thanks for your time.
Quote:
I can probably fix it in the splitter, though.
Only if you have extra time.
__________________
[ Download ffdshow | Wiki ]
haruhiko_yamagata is offline   Reply With Quote
Old 7th February 2012, 16:32   #14673  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,962
After fixing the source, LAV Video in software mode still cannot decode it, must be a problem in libav/ffmpeg itself. If i run it though CUDA or the Intel decoder, it works just fine.

For the record, it never worked with Haali for me either.

Edit:
I actually fixed it, the file is just muxed very badly. It doesn't work 100% from the start .. but it works, kind of.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 7th February 2012 at 17:28.
nevcairiel is online now   Reply With Quote
Old 8th February 2012, 20:47   #14674  |  Link
kc7bfi
Registered User
 
Join Date: Nov 2010
Location: Chesapeake, VA USA
Posts: 38
Quote:
Originally Posted by nevcairiel View Post
That file is odd, whatever muxed it is a broken application.
It muxed an AnnexB stream into MKV, which in itself is not wrong, BUT it created MP4 style extradata. Either you mux in AnnexB mode, or in MP4 mode, combining the two is .... weird. Horrible.

I can probably fix it in the splitter, though.
I must confess that I am not very familiar with the finer points of H.264 video nor its packaging. Also, it may be possible that something went wrong woth the MKV file creation, but I have a few questions:

1) Do you see the same "muxed" issues in the wireshark?
2) Would this explain the DebugView log I included in a previous message?
3) Would there have been something changed between revisions 4175 and 4176 that would have caused this problem?

It it would be helpful I could create a small program that will play the video from the encoder (over the Internet) using the ffdshow filter for decoding. Just let me know. David
kc7bfi is offline   Reply With Quote
Old 8th February 2012, 23:51   #14675  |  Link
haruhiko_yamagata
Registered User
 
Join Date: Feb 2006
Location: Japan
Posts: 1,560
Quote:
Originally Posted by kc7bfi View Post
I must confess that I am not very familiar with the finer points of H.264 video nor its packaging. Also, it may be possible that something went wrong woth the MKV file creation, but I have a few questions:

1) Do you see the same "muxed" issues in the wireshark?
How can I analyze it? I won't read bit-stream using binary editor. I'm not a computer.
Quote:
2) Would this explain the DebugView log I included in a previous message?
The debug log indicates the stream is broken. Or it may be indicating the bug of the source/splitter filter or ffdshow.
Quote:
3) Would there have been something changed between revisions 4175 and 4176 that would have caused this problem?
Rev 4176 changes the way of calculation of NAL unit size. As the mkv file shown, the upper stream filter must not use start code "00 00 01" if the container is mkv or mp4. It must use NAL unit size instead. Microsoft's guideline. Does simply changing the FOURCC work? If your source is RTSP, I don't know how NAL unit size is handled in DirectShow. I think the guideline still should be followed. If I'm wrong, please correct me.
Quote:
It it would be helpful I could create a small program that will play the video from the encoder (over the Internet) using the ffdshow filter for decoding. Just let me know. David
That would help a lot. I'll wait for it.
__________________
[ Download ffdshow | Wiki ]
haruhiko_yamagata is offline   Reply With Quote
Old 9th February 2012, 05:10   #14676  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 658
I tried enabling software scaling, but it seems to me the aspect ratio handling might not be working as expected.

I tried to play a 16/9 movie on a 16/10 LCD (1680x1050), so I followed the instructions here: http://ffdshow-tryout.sourceforge.ne...:resize_aspect

(That means, "specify horizontal and vertical size" enabled, set to: 1680x1050, "keep original aspect ratio" enabled, "process pixel aspect ratio internally" enabled. At the same time, I disabled "keep aspect ratio" in mpc as the help entry suggests.)

If I understand the help properly, this should scale the image, keeping the aspect ratio, until width or height hits the specified dimensions. However, ffdshow will also pad the image with black bars to meet the specified resolution on top of that, it will expand 4:3 or 16:9 frame to the full 16/10 of the LCD.
This has two weird consequences: subtitle positioning is changed, and if you switch the player to window, the black bars padding will affect the windowed display.

Is this how it is supposed to work, or am I missing something? I'm afraid don't recall how the function behaved in the past, so I have no idea if this is actually a regression or standard behaviour...

(revision tested: 4296, x86 MSVC buld from xvidvideo.ru; windows XP sp3 home, MPC-HC 1.5.3.3819)

P.S. If the padding is intentional, I'd like to suggest adding an option to disable it. It would make the scaling more useful if ASS subtitles that rely on positioning are used.

Last edited by mandarinka; 9th February 2012 at 05:17.
mandarinka is offline   Reply With Quote
Old 9th February 2012, 06:02   #14677  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 4,669
As the documentation says: If you specify both height and width, then ffdshow will resize to that exact resolution. Padding is required if the aspect ratio of the video differs from your target resolution.

If you don't want padding you need to create two profiles:
aspect < 16/10 -> specify height
aspect >= 16/10 -> specify width

Disabling that option in MPC should not be needed.
clsid is offline   Reply With Quote
Old 9th February 2012, 07:45   #14678  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,962
Quote:
Originally Posted by haruhiko_yamagata View Post
the upper stream filter must not use start code "00 00 01" if the container is mkv or mp4. It must use NAL unit size instead.
Thats not true, MKV is fine with start-code based H264, that particular file has just mixed both solutions into one.

The stream itself works fine with various hardware decoders i tried, it seems to be an issue with the software decoder.
I do actually get an image now with LAV, but the first few frames are missing.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 9th February 2012, 10:29   #14679  |  Link
haruhiko_yamagata
Registered User
 
Join Date: Feb 2006
Location: Japan
Posts: 1,560
Quote:
Originally Posted by nevcairiel View Post
Thats not true, MKV is fine with start-code based H264
Thanks for the info. I didn't know.
__________________
[ Download ffdshow | Wiki ]
haruhiko_yamagata is offline   Reply With Quote
Old 9th February 2012, 13:06   #14680  |  Link
haruhiko_yamagata
Registered User
 
Join Date: Feb 2006
Location: Japan
Posts: 1,560
@kc7bfi,
How does your filter feed SPS/PPS to ffdshow?
Is it given as codec private data on connection? or is it given to IMemInputPin::Receive?
How NAL unit size is handled for SPS/PPS?
__________________
[ Download ffdshow | Wiki ]
haruhiko_yamagata is offline   Reply With Quote
Reply

Tags
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.