Menu
▾
▴
libmpeg2-devel
|
From: Gert V. <Ger...@wx...> - 2001-11-02 18:41:09
|
Hi,
With the following path libmpeg2 is able to decode HDTV streams.
Gert
--- mpeg2dec/libmpeg2/header.c.1 Fri Nov 2 19:36:48 2001
+++ mpeg2dec/libmpeg2/header.c Fri Nov 2 19:37:15 2001
@@ -87,9 +87,6 @@
width = ((height >> 12) + 15) & ~15;
height = ((height & 0xfff) + 15) & ~15;
- if ((width > 768) || (height > 576))
- return 1; /* size restrictions for MP@ML or MPEG1 */
-
picture->coded_picture_width = width;
picture->coded_picture_height = height;
|
|
From: Michel L. <wa...@zo...> - 2001-11-04 11:41:37
|
On Fri, Nov 02, 2001 at 07:42:25PM +0100, Gert Vervoort wrote: > With the following path libmpeg2 is able to decode HDTV streams. > - if ((width > 768) || (height > 576)) > - return 1; /* size restrictions for MP@ML or MPEG1 */ > - Hmmm. Right, we dont need much to be able to decode MP@HL instead of just MP@ML. I'm about to commit a patch to CVS for this. I'm not totally removing the size restrictions though, because we still dont support arbitrary size - for pictures higher than 2800 lines, we would need some special support that we dont have right now. If you need resolutions higher than 1920x1152, let me know (in which case I also need to know what the corresponding maximum VBV buffer size is - I've been taking the parameters for MP@HL as a reference there). Cheers, -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. |
|
From: Peter G. <pe...@el...> - 2001-11-05 02:54:41
|
Hi Michel, I've promised you to share some interesting streams long ago. But the streams I had turned to be not so interested. Finally I've got something for you. Download ftp://nimbus.elecard.net.ru/pub/mpeg/transport/CH_49-1.ts.0000 This is a transport stream captured from FOX broadcast with HiPix card. It contains regular SDTV video stream. But this stream doesn't contain any I frames! The file is 144MB, but if you don't want to wait too much, 8MB of it would be enough to understand. I haven't found any hints like intra refresh yet, but I'll keep trying to find standard compliance of this stream. Have fun! Peter |
|
From: Peter G. <pe...@el...> - 2001-11-05 03:27:29
|
Well, I've managed to find the required paragraph in the MPEG spec: 6.1.1.11 Frame reordering When the sequence contains coded B-frames, the number of consecutive coded B-frames is variable and unbounded. The first coded frame after a sequence header shall not be a B-frame. A sequence may contain no coded P-frames. A sequence may also contain no coded I-frames in which case some care is required at the start of the sequence and within the sequence to effect both random access and error recovery. .... Fortunately, libmpeg2 doesn't care whether it is capable of decoding a frame or not, so this is not a problem. There could be problems for applications that will display blocky frames. And there are no means to guarantee the frame contains no errors except temporal stream analysis ;-) So, put a new stream to your collection. Cheers, Peter Peter Gubanov wrote: > Hi Michel, > > I've promised you to share some interesting streams long ago. But the > streams I had turned to be not so interested. Finally I've got > something for you. Download > ftp://nimbus.elecard.net.ru/pub/mpeg/transport/CH_49-1.ts.0000 This is > a transport stream captured from FOX broadcast with HiPix card. It > contains regular SDTV video stream. But this stream doesn't contain > any I frames! The file is 144MB, but if you don't want to wait too > much, 8MB of it would be enough to understand. I haven't found any > hints like intra refresh yet, but I'll keep trying to find standard > compliance of this stream. > > Have fun! > > Peter > > > > > > _______________________________________________ > Libmpeg2-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel > > |
|
From: Michel L. <wa...@zo...> - 2001-11-05 07:52:06
|
OK, so I'm still downloading the stream, but you make me feel glad already that I integrated the new TS demuxer into mpeg2dec :)) On Mon, Nov 05, 2001 at 10:27:02AM +0700, Peter Gubanov wrote: > 6.1.1.11 Frame reordering > When the sequence contains coded B-frames, the number of consecutive > coded B-frames is variable and unbounded. The first coded frame after a > sequence header shall not be a B-frame. > A sequence may contain no coded P-frames. A sequence may also contain > no coded I-frames in which case some care is required at the start of > the sequence and within the sequence to effect both random access and > error recovery. I had digital cable TV previously, and I had noticed how you can see the screen refresh after switching channels. Also one known case where they dont use I frames is videoconferencing - basically to achieve lower latency they dont use I frames because that would require a bigger stream buffer and thus more buffering latency, and they dont use B frames either because of the reordering latency, so they are stuck with only P frames and intra refresh. But yeah, these streams are pretty unusual, and I never saw one before that used B frames as well. I'll add it in my test suite :) > Fortunately, libmpeg2 doesn't care whether it is capable of decoding a > frame or not, so this is not a problem. There could be problems for > applications that will display blocky frames. And there are no means to > guarantee the frame contains no errors except temporal stream analysis ;-) I will send this to guenter of the xine project, I suspect it will be a problem for them. I dont know how people could deal with this without stream analysis - one possible way would be to rely on the fact that it is invalid in MPEG2 to send more than 132 IDCT updates to a given pixel value, but I think this doesnt work because non-coded blocks are not included in this count... > So, put a new stream to your collection. If you see other funny streams I'm always interested to see these :) PS whats up with you lately ? -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. |
|
From: Peter G. <pe...@el...> - 2001-11-05 08:31:12
|
>OK, so I'm still downloading the stream, but you make me feel glad >already that I integrated the new TS demuxer into mpeg2dec :)) > I can demux video for you if you like. But I've looked at the code briefly, and I suppose there should be no problems getting the video stream out of the transport. >I had digital cable TV previously, and I had noticed how you can see >the screen refresh after switching channels. Also one known case where > I've got a number of captured streams, European, US, Chineese - all of them are regular streams with I-frames. This FOX broadcast is something unusual. No I-frames, alternate scan, 10 bit DC precision... I haven't ever seen such streams. > >they dont use I frames is videoconferencing - basically to achieve >lower latency they dont use I frames because that would require a >bigger stream buffer and thus more buffering latency, and they dont >use B frames either because of the reordering latency, so they are >stuck with only P frames and intra refresh. > Yes, this is known as "low delay" mode. They use intra slices to refresh. > >I will send this to guenter of the xine project, I suspect it will be >a problem for them. > Heh. There are no problems for decoder - there are problems for users who have watch broken frames ;-) > >I dont know how people could deal with this without stream analysis - >one possible way would be to rely on the fact that it is invalid in >MPEG2 to send more than 132 IDCT updates to a given pixel value, but I >think this doesnt work because non-coded blocks are not included in >this count... > Where did you get the number? And who ever managed to count a number of updates for a particular pixel? There is "intra slice" flag in MPEG slice header, but it is never used by decoder and rarely used by encoders. It is intended primarily for DSM CC. But personally I now no more than 4 implementations os DSM CC... > >If you see other funny streams I'm always interested to see these :) > You're welcome! As fas as Elecard implements more fixes to the decoder and demultiplexer, we receive less streams ;-( > >PS whats up with you lately ? > Just busy too much. I know I've promised some checkins to libmpeg2, but there are new problems every day on my primary projects, and I waste time. Students, PhD thesis, junior collegues - all takes so much time... But it seems I will have some time to breath freely in the nearest future ;-) Peter |
|
From: Michel L. <wa...@zo...> - 2001-11-05 09:02:16
|
On Mon, Nov 05, 2001 at 03:30:19PM +0700, Peter Gubanov wrote: > I can demux video for you if you like. But I've looked at the code > briefly, and I suppose there should be no problems getting the video > stream out of the transport. No, you dont need to demux it - mpeg2dec -t 11 on this stream works just fine :) > Where did you get the number? And who ever managed to count a number of > updates for a particular pixel? There is "intra slice" flag in MPEG > slice header, but it is never used by decoder and rarely used by > encoders. It is intended primarily for DSM CC. But personally I now no > more than 4 implementations os DSM CC... The thing about 132 idct updates is in mpeg2 annex A. They also refer you to section 2.3 of the IEEE1180 standard. But you're right, in practice this is impossible to use, since you'd have to follow up pixels as they are motion compensated... > Just busy too much. I know I've promised some checkins to libmpeg2, but > there are new problems every day on my primary projects, and I waste > time. Students, PhD thesis, junior collegues - all takes so much time... > But it seems I will have some time to breath freely in the nearest > future ;-) :)) A lot of the same here... been busy but I always hope to get more time. Cheers, -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. |
|
From: Peter G. <pe...@el...> - 2001-11-05 10:05:56
|
>The thing about 132 idct updates is in mpeg2 annex A. They also refer >you to section 2.3 of the IEEE1180 standard. But you're right, in >practice this is impossible to use, since you'd have to follow up >pixels as they are motion compensated... > Aha! Here it is: NOTES - 1 Clause 2.3 Std 1180-1990 =93Considerations of Specifying IDCT=20 Mismatch Errors=94 requires the specification of periodic intra-picture=20 coding in order to control the accumulation of mismatch errors. Every=20 macroblock is required to be refreshed before it is coded 132 times as=20 predictive macroblocks. Macroblocks in B-pictures (and skipped=20 macroblocks in P-pictures) are excluded from the counting because they=20 do not lead to the accumulation of mismatch errors. This requirement is=20 the same as indicated in 1180-1990 for visual telephony according to=20 ITU-T Recommendation H.261. But fortunately, it stated for macroblocks, not for pixels. ;-) A bit=20 easier to care about, but I haven't ever seen a encoder which cared.=20 BTW, I have tested my encoding engine and generated a stream of 1000=20 frames. It contained 1 I frame and 999 P frames, all predcted. The=20 mismatch error becomes rather noticable even despite I use exactly the=20 same IDCT for encoder and decoder, and encoder is closed loop (i.e. it=20 reconstructs a reference picture before predicting the next). >:)) A lot of the same here... been busy but I always hope to get more >time. > Hope dies hard! ;-) Peter |
|
From: Michel L. <wa...@zo...> - 2001-11-06 10:30:35
|
On Mon, Nov 05, 2001 at 05:05:15PM +0700, Peter Gubanov wrote: > But fortunately, it stated for macroblocks, not for pixels. ;-) A bit > easier to care about, but I haven't ever seen a encoder which cared. > BTW, I have tested my encoding engine and generated a stream of 1000 > frames. It contained 1 I frame and 999 P frames, all predcted. The > mismatch error becomes rather noticable even despite I use exactly the > same IDCT for encoder and decoder, and encoder is closed loop (i.e. it > reconstructs a reference picture before predicting the next). Oh ? weird. How does thar error look like, I suppose this is high-frequency noise ? -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. |
|
From: Peter G. <pe...@el...> - 2001-11-06 10:53:38
|
> >Oh ? weird. How does thar error look like, I suppose this is >high-frequency noise ? > Not only HF - the picture becomes lighter and lighter, color shifts to blue. Actually, this depends on the content, so the pciture may go darker and red on different material. I guess this is natural, because we use statistically accurate iDCT and MC, and rounding errors become visible after 100 iterations on the same macroblock. Peter |
|
From: Michel L. <wa...@zo...> - 2001-11-06 11:23:40
|
On Tue, Nov 06, 2001 at 05:52:50PM +0700, Peter Gubanov wrote: > >Oh ? weird. How does thar error look like, I suppose this is > >high-frequency noise ? > Not only HF - the picture becomes lighter and lighter, color shifts to > blue. Actually, this depends on the content, so the pciture may go > darker and red on different material. I guess this is natural, because > we use statistically accurate iDCT and MC, and rounding errors become > visible after 100 iterations on the same macroblock. OK... Well I still dont understand, because you said you use the same IDCT in the encoder and the decoder, and in that case errors should not accumulate... basically the prediction frames should be bitwise identical in the encoder and the decoder and so there is no reason to get error accumulation... is there ? Also given our statistics in the IEEE tests, I dont see that the errors should be visible after 100 frames. In my maths the errors should still be a deviation of about 1 level of gray after 100 frames - not anything noticeable really. This weekend I've been looking at an ffmpeg bug related to IDCT and I couldnt put my finger on it. They use our IDCT and for some streams (basically one stream that has very little I pictures, I think one I every 100 or 132 pictures) they get bad error accumulation, in the form of horizontal stripes and/or color drift. Someone came up with a different IDCT routine, that doesnt behave much better than ours in the IEEE tests (ok, about 5-10% better), but does not show up this error accumulation. This is all in their divx codec. But I dont understand: according to the IEEE tests our worst mean square error is 0.01, and our worst mean error (which is what should really matter for error accumulation) is 0.0026. So even if you multiply these by 100 or 132, you really shouldnt get anything noticeable at all !!!!! somehow it seems that the stastistical tests do not match the behaviour of their divx codec, and I can not understand why at all. Any idea about this ? Puzzled, -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. |
|
From: Peter G. <pe...@el...> - 2001-11-06 11:46:22
|
>Well I still dont understand, because you said you use the same IDCT >in the encoder and the decoder, and in that case errors should not >accumulate... basically the prediction frames should be bitwise >identical in the encoder and the decoder and so there is no reason to >get error accumulation... is there ? Also given our statistics in the >IEEE tests, I dont see that the errors should be visible after 100 >frames. In my maths the errors should still be a deviation of about 1 >level of gray after 100 frames - not anything noticeable really. > Don't forget about quantizer and saturation. I'm not sure there are no bugs in the encoder. I guess the inverse quantizers are slightly different, and this iduces errors %-) But you are right, equal routines produce equal rounding errors, so the result in both decoders should be equal. BTW, I recall I have used a different decoder to view the result... It was MProbe, I suppose. %-) >This weekend I've been looking at an ffmpeg bug related to IDCT and I >couldnt put my finger on it. They use our IDCT and for some streams >(basically one stream that has very little I pictures, I think one I >every 100 or 132 pictures) they get bad error accumulation, in the >form of horizontal stripes and/or color drift. Someone came up with a >different IDCT routine, that doesnt behave much better than ours in >the IEEE tests (ok, about 5-10% better), but does not show up this >error accumulation. This is all in their divx codec. But I dont >understand: according to the IEEE tests our worst mean square error is >0.01, and our worst mean error (which is what should really matter for >error accumulation) is 0.0026. So even if you multiply these by 100 or >132, you really shouldnt get anything noticeable at all !!!!! somehow >it seems that the stastistical tests do not match the behaviour of >their divx codec, and I can not understand why at all. > Are you sure they haven't changed anything else except the idct? They can add error in motion compensation, block adding, etc. Stripes don't appear suddenly after 132 frames. And if there is a problem with idct, they should appear on luma much earlier. > >Any idea about this ? > I'd like to take a look at this first before I say anything. Peter |
|
From: Michel L. <wa...@zo...> - 2001-11-08 08:25:52
|
On Tue, Nov 06, 2001 at 06:45:41PM +0700, Peter Gubanov wrote: > Don't forget about quantizer and saturation. I'm not sure there are > no bugs in the encoder. I guess the inverse quantizers are slightly > different, and this iduces errors %-) But you are right, equal > routines produce equal rounding errors, so the result in both > decoders should be equal. Yes, normally the only possible difference should be in the IDCT, so any differences should be either due to a bug or to IDCT differences. > >This weekend I've been looking at an ffmpeg bug related to IDCT and I > >couldnt put my finger on it. They use our IDCT and for some streams > >(basically one stream that has very little I pictures, I think one I > >every 100 or 132 pictures) they get bad error accumulation, in the > >form of horizontal stripes and/or color drift. Someone came up with a > >different IDCT routine, that doesnt behave much better than ours in > >the IEEE tests (ok, about 5-10% better), but does not show up this > >error accumulation. This is all in their divx codec. But I dont > >understand: according to the IEEE tests our worst mean square error is > >0.01, and our worst mean error (which is what should really matter for > >error accumulation) is 0.0026. So even if you multiply these by 100 or > >132, you really shouldnt get anything noticeable at all !!!!! somehow > >it seems that the stastistical tests do not match the behaviour of > >their divx codec, and I can not understand why at all. > Are you sure they haven't changed anything else except the idct? They > can add error in motion compensation, block adding, etc. Stripes don't > appear suddenly after 132 frames. And if there is a problem with idct, > they should appear on luma much earlier. its not suddenly - they appear progressively, and then disappear suddenly (probably at the next I frame). > I'd like to take a look at this first before I say anything. Download mplayer: http://www.MPlayerHQ.hu/homepage/dload.html Download streams from ftp://mplayerhq.hu/MPlayer/samples/ffmpeg-bugs/HorizontalStripesDivX.avi and ftp://mplayerhq.hu/MPlayer/samples/Divx4-bugs/Lorenna_McKennit-Mummers_Dance-Mononoke_Hime-gabucino.avi run with mplayer -vc ffdivx foo.avi apply the attached patch and compare HorizontalStripes has (faint, but still visible, and statistically they shouldnt be visible) stripes, and Lorenna has weird colors at some points. -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. |
|
From: Peter G. <pe...@el...> - 2001-11-08 10:14:21
|
>Download mplayer: http://www.MPlayerHQ.hu/homepage/dload.html > >Download streams from >ftp://mplayerhq.hu/MPlayer/samples/ffmpeg-bugs/HorizontalStripesDivX.avi >and >ftp://mplayerhq.hu/MPlayer/samples/Divx4-bugs/Lorenna_McKennit-Mummers_Dance-Mononoke_Hime-gabucino.avi > I've looked at both streams with DivX 4.0 beta decoder under Windows. And I don't see any stripes. There are motion compensation/estimation errors on the second stream (Lorenna....), but those stripes have nothing to do with idct - they are clearly MC related. >run with mplayer -vc ffdivx foo.avi > >apply the attached patch and compare > Gonna check this later today or tomorrow. > >HorizontalStripes has (faint, but still visible, and statistically >they shouldnt be visible) stripes, and Lorenna has weird colors at >some points. > Could you tell me time/frame positions? Maybe I miss something... Peter |
|
From: Michel L. <wa...@zo...> - 2001-11-08 21:40:26
|
On Thu, Nov 08, 2001 at 05:13:38PM +0700, Peter Gubanov wrote: > >run with mplayer -vc ffdivx foo.avi > >apply the attached patch and compare > Gonna check this later today or tomorrow. > >HorizontalStripes has (faint, but still visible, and statistically > >they shouldnt be visible) stripes, and Lorenna has weird colors at > >some points. > Could you tell me time/frame positions? Maybe I miss something... Well in HorizontalStripes, I can see some faint but visible stripes on the mostly-uniform greyish background at the start of the movie. In the Lorenna stream it looks more like color drift, like if you had some bias in the IDCT and after a while the colors are purple-ish. You can see that best in the crossfade around the end of that stream - it doesnt look the same if you apply the simple_idct patch. Basically the simple_idct patch seems to behave better than "our" idct on both of these streams, even though they have almost identical precision when running the ieee1180 tests. I'm puzzled. I suspect you wont see any of this when using the windows divx decoder, as it probably matches exactly what the encoder is doing anyways. Cheers, -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. |
|
From: Billy B. <ve...@du...> - 2001-11-08 22:28:39
|
Michel LESPINASSE (wa...@zo...): > I suspect you wont see any of this when using the windows divx > decoder, as it probably matches exactly what the encoder is doing > anyways. Careful, I've heard it does some deblocking/blurring to remove encoding artifacts. So, it may be that you're just not seeing it because it's been filtered. -- Billy Biggs ve...@du... |
|
From: Arpi <ar...@th...> - 2001-11-08 22:34:11
|
Hi, > Michel LESPINASSE (wa...@zo...): > > > I suspect you wont see any of this when using the windows divx > > decoder, as it probably matches exactly what the encoder is doing > > anyways. > > Careful, I've heard it does some deblocking/blurring to remove > encoding artifacts. So, it may be that you're just not seeing it > because it's been filtered. no, no. it's visible wven with disabled postprocessing. btw postproc filter can't remove these artifacts, we tried. A'rpi / Astral & ESP-team -- mailto:ar...@th... http://esp-team.scene.hu |
|
From: Arpi <ar...@th...> - 2001-11-07 00:51:00
|
Hi, > Well I still dont understand, because you said you use the same IDCT > in the encoder and the decoder, and in that case errors should not > accumulate... basically the prediction frames should be bitwise > identical in the encoder and the decoder and so there is no reason to > get error accumulation... is there ? Also given our statistics in the > IEEE tests, I dont see that the errors should be visible after 100 > frames. In my maths the errors should still be a deviation of about 1 > level of gray after 100 frames - not anything noticeable really. you should try to dump idct blocks from that broken files, and do some testing with them. what about some code to do idct with both algo (your and Michael's) and compare results, and save block if differs, so you can do further tests with them? btw, idct artifacts usually come at constant, bright, flat parts of the image. like white walls, light-blue sky. maybe it's from handling boundaries (0/255 limits). > (basically one stream that has very little I pictures, I think one I > every 100 or 132 pictures) they get bad error accumulation, in the usually 500-1000. (every 10-20 secs) A'rpi / Astral & ESP-team -- mailto:ar...@th... http://esp-team.scene.hu |
|
From: Arpi <ar...@th...> - 2001-11-06 13:06:34
|
Hi, > > > >Oh ? weird. How does thar error look like, I suppose this is > >high-frequency noise ? > > > Not only HF - the picture becomes lighter and lighter, color shifts to > blue. Actually, this depends on the content, so the pciture may go > darker and red on different material. I guess this is natural, because > we use statistically accurate iDCT and MC, and rounding errors become > visible after 100 iterations on the same macroblock. hmm. the same thing happened in ffmpeg, using Walken's idct code. did you tried with plain C idct code? A'rpi / Astral & ESP-team -- mailto:ar...@th... http://esp-team.scene.hu |
|
From: Gert V. <ger...@wx...> - 2001-11-05 18:00:17
|
Michel LESPINASSE wrote: > > On Fri, Nov 02, 2001 at 07:42:25PM +0100, Gert Vervoort wrote: > > With the following path libmpeg2 is able to decode HDTV streams. > > > - if ((width > 768) || (height > 576)) > > - return 1; /* size restrictions for MP@ML or MPEG1 */ > > - > > Hmmm. Right, we dont need much to be able to decode MP@HL instead of > just MP@ML. I'm about to commit a patch to CVS for this. > > I'm not totally removing the size restrictions though, because we > still dont support arbitrary size - for pictures higher than 2800 > lines, we would need some special support that we dont have right now. > Are there any resolutions possible in MPEG-2 higher then 1920x1152? If I look into the table with the definitions of the profiles and levels, this is the highest resolution mentioned. Gert |
|
From: Michel L. <wa...@zo...> - 2001-11-06 09:33:53
|
On Mon, Nov 05, 2001 at 06:50:40PM +0100, Gert Vervoort wrote: > Are there any resolutions possible in MPEG-2 higher then 1920x1152? > If I look into the table with the definitions of the profiles and > levels, this is the highest resolution mentioned. Well, the mpeg2 syntax allows for streams up to 16383x16383 I think. However most streams follows one of the published profiles, and the highest ones are at 1920x1152. But, it is always possible to make a stream that doesnt follow any of the profiles. The problem right now is that libmpeg2 uses a limited-size buffer to store data chunks - and the size of that buffer is determined by the highest profile and level that we support. So, just increasing the resolution would not be enough to support these streams, we would need to increase the buffer size too... -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X