From: Bob I. <bo...@br...> - 2009-03-19 23:58:07
|
Thanks Måns. The better result that I am seeking from libmpeg2 is better error detection and concealment. I don't know if it is better in this way or not, but I have tweaked various CodecContext variables in libavcodec and I am still getting too many artifacts. Regarding non-compliant TS streams from LinuxDVB: I am currently using a DMX_SET_PES_FILTER with its pes_type member set to DMX_PES_OTHER. Since I a wanting video, perhaps I should change this to DMX_PES_VIDEO and perhaps I will get a standard TS/PES stream. Or maybe that's how DMX_SET_PES_FILTER works. All I know is that, after stripping-off the 4-byte TS header (and any adaption-field header, if present,) the remaining bytes are the raw compressed MPEG2 frames bytes. When I get a complete frame and decode/render it, I see the picture I expect. The libavcodec MPEG2 decoder is reporting normal sequences of I/P/B frames all along the way. Strange... Thanks for your insights. Bob Bob Ingraham <bo...@br...> writes: > Hi All, > > I've written an app which uses the Linux DVB API to pull down an MPEG2-TS. > > Currently it: > > 1. Decodes the TS header > 2. Extracts the MPEG2 encoded frame > 3. Decompresses it with libavcodec (an ffmpeg library) > 4. Renders it with SDL > > But I wanted to try libmpeg2 to see if it's decoder will yield > better results than libavcodecs. Better in what way? > Questions: > > 1. Does libmpeg2 perform steps 1 through 3 above? No, it only does step 3. > 2. Can I just pass an compressed MPEG2 frame to libmpeg2 (without > any PS, TS or PES headers?) Yes, in fact you have to. > 3. Apparently, the Linux DVB API filter removes all PES headers and > hands me a TS stream with just the raw mpeg2 frames after the > TS/adaption field header. No, this is incorrect. > I don't think this is normal, because the MPEG2 spec says that mpeg2 > frames should be encapsulated within PES packets within the TS > frames. > > Does this seem odd that there are no PES header? Check again or change some setting. I know I have got proper TS streams from the Linux DVB interface. -- Måns Rullgård ma...@ma... |
From: Bob I. <bo...@br...> - 2009-03-20 01:39:18
|
Good news! Shortly after I wrote that last email I found that the cause of many (but not all,) of my major artifacts was my coding error in decoding the adaptation field length. After re-reading the MPEG2 spec, I realized that I was one byte too short in calculating the byte offset of the payload when a adapation field was present in the TS packet. Hence, the frequent major artifacts were a result of one extra byte of data before the actual mpeg2 frame. So, I am an idiot! How exciting is that? :-) Anyway, the image is much more stable. However I still get a *lot* of artifacts when displaying a live shot of the ocean waves crashing onto a beach in California. (I work for a satellite company and we have some hi-def, fixed cameras at this particular beach...) The edges of the waves, along with white caps on the waves definitely cause grief, but the biggest problem is the OSD of the clock-time superimposed on the frames (it changes every second,) - it looks like the time gets washed torwards the shore every time a wave passes through it. Also, the digits of the numbers are supposed to be white and they keep turning rainbow colors... But, as sanity check, I a comparing the same satellite feed coming through libavcodec versus a commercial mpeg2 receiver, and the mpeg2 receiver has zero-problems with the OSD clock overlay. The time-digits are steady and white and the blockiness of the waves is finer grained. Michael, I respect your work, knowledge and contributions to ffmpeg and would happy to post a stream capture of the live beach video tomorrow for folks to test with. Based on the above descripton, do you have any recommendations for tweaking the CodecContext (or applying a post-processing filter to smooth-out the wave edges?) Best Regards, Bob Ingraham ----- Original Message ----- From: "Michael Niedermayer" <mic...@gm...> To: "Bob Ingraham" <bo...@br...> Cc: lib...@li... Sent: Thursday, March 19, 2009 6:39:05 PM GMT -07:00 US/Canada Mountain Subject: Re: [mpeg2-dev] Decoding MPEG-TS stream On Thu, Mar 19, 2009 at 05:55:09PM -0600, Bob Ingraham wrote: > Thanks Måns. > > The better result that I am seeking from libmpeg2 is better error detection and concealment. I belive libmpeg2 does no error concealment > > I don't know if it is better in this way or not, but I have tweaked various CodecContext variables in libavcodec and I am still getting too many artifacts. This is strange, could you make a short piece of the stream available for other to check (that is a part which shows too many artifacts) also you should be able to test the stream with mplayer, mplayer supports both libmpeg2 and libavcodec [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator |
From: Michael N. <mic...@gm...> - 2009-03-20 01:59:56
|
On Thu, Mar 19, 2009 at 07:35:49PM -0600, Bob Ingraham wrote: > Good news! > > Shortly after I wrote that last email I found that the cause of many (but not all,) of my major artifacts was my coding error in decoding the adaptation field length. > > After re-reading the MPEG2 spec, I realized that I was one byte too short in calculating the byte offset of the payload when a adapation field was present in the TS packet. Hence, the frequent major artifacts were a result of one extra byte of data before the actual mpeg2 frame. > > So, I am an idiot! How exciting is that? :-) > > Anyway, the image is much more stable. However I still get a *lot* of artifacts when displaying a live shot of the ocean waves crashing onto a beach in California. (I work for a satellite company and we have some hi-def, fixed cameras at this particular beach...) > > The edges of the waves, along with white caps on the waves definitely cause grief, but the biggest problem is the OSD of the clock-time superimposed on the frames (it changes every second,) - it looks like the time gets washed torwards the shore every time a wave passes through it. Also, the digits of the numbers are supposed to be white and they keep turning rainbow colors... > > But, as sanity check, I a comparing the same satellite feed coming through libavcodec versus a commercial mpeg2 receiver, and the mpeg2 receiver has zero-problems with the OSD clock overlay. The time-digits are steady and white and the blockiness of the waves is finer grained. > > Michael, I respect your work, knowledge and contributions to ffmpeg and would happy to post a stream capture of the live beach video tomorrow for folks to test with. > > Based on the above descripton, do you have any recommendations for tweaking the CodecContext (or applying a post-processing filter to smooth-out the wave edges?) You shouldnt draw into the internal buffers of libavcodec, it uses them for predicting future frames. Also you likely want to read the docs about get/relealse_buffer() about postprocessing, theres libpostproc and some filters in mplayers libmpcodecs like vf_spp, later is significantly slower but higher quality [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser. |
From: Michael N. <mic...@gm...> - 2009-03-20 00:41:19
|
On Thu, Mar 19, 2009 at 05:55:09PM -0600, Bob Ingraham wrote: > Thanks Måns. > > The better result that I am seeking from libmpeg2 is better error detection and concealment. I belive libmpeg2 does no error concealment > > I don't know if it is better in this way or not, but I have tweaked various CodecContext variables in libavcodec and I am still getting too many artifacts. This is strange, could you make a short piece of the stream available for other to check (that is a part which shows too many artifacts) also you should be able to test the stream with mplayer, mplayer supports both libmpeg2 and libavcodec [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator |