Re: [Opensvcdecoder-support] Problem decoding IDR pictures

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,
> We noticed that when we change the framerate, the player continues to decode with the initial one and the stream is accelerated or slowed down. We thought that the most efficient way is to inform the decoder about any modification applied to the stream by using an SEI message.

which player are you talking about? Mplayer?

You might consider to inform the player with SEI messages -- not the decoder -- to use such information. I don't see the case where it is useful in the decoder.

> Do you have any knowledge if there is a trick to make the decoder adapt to the new framerate ?
With Mplayer there is a trick using the keyboard. You can find all information here:
http://sourceforge.net/apps/mediawiki/opensvcdecoder/index.php?title=Mplayer#SVC_Features_in_MPlayer.

In the decoder API you can use settemporalID to change the decoding framerate.

Let us know if it works?

Best regards,
Mickaël

>  
> Regards,
> Selim
>  
> De : Mickaël Raulet [mailto:mr...@gm...] De la part de Mickaël Raulet
> Envoyé : mercredi 30 juin 2010 17:13
> À : ELLOUZE Selim RD-CORE-LAN
> Cc : med...@in...; ope...@li...
> Objet : Re: [Opensvcdecoder-support] Problem decoding IDR pictures
>  
> Hi selim,
>  
> we bypass SEI messages at this stage. It is not normative, just informative in the spec.
>  
> Could you tell us why you need them?
>  
> Best regards, 
> Mickaël
>  
> Le 30 juin 2010 à 17:08, <sel...@or...> a écrit :
> 
> 
> Hello Mederic,
>  
> I will try with the value 0 and let you know about the results.
> Concerning the scalability SEI message, do you have an idea if opensvcdecoder supports such messages ? and if we could use it to inform the decoder about a framerate change or any modification of the stream ?
>  
> Best regards,
> Selim    
>  
> De : mblestel [mailto:med...@in...] 
> Envoyé : mercredi 30 juin 2010 09:55
> À : ELLOUZE Selim RD-CORE-LAN
> Cc : ope...@li...
> Objet : Re: [Opensvcdecoder-support] Problem decoding IDR pictures
>  
> Hello Selim,
> 
> 
> Thank you for testing the decoder.
> 
> Having a look to your cfg files, I point out that you are using MGS Vectors eqauls to 1
> I think that the problem can come from this option.
> 
> You should try with MGS Vector equals to 0.
> 
> I will try to solve the bug with the MGS Vector option.
> 
> Kind regards
> 
> Médéric
> 
> 
> 
> sel...@or... a écrit :
> Hello again,
>  
> Please find attached 3 streams containing MGS layers:
> DQD : L0Q1 (working)
> DQDQ : L0Q1 + L1Q1 (not working fine)
> DDQ : L1Q1 (not working fine)
>  
> If you have any configuration scheme where MGS layers are decoded fine, could you please send it to me that will be of great help.
>  
> Otherwise, is the opensvcdecoder capable of handling the SEI messages? Especially the SSEI or the layers not present SEI message. Our intention is to provide such messages when modifying the stream in order to let the player know about the new stream characteristics.
>  
> Thankfully,
> Selim
>  
>  
>  
> De : mblestel [mailto:med...@in...] 
> Envoyé : mercredi 16 juin 2010 09:16
> À : ELLOUZE Selim RD-CORE-LAN
> Cc : ope...@li...
> Objet : Re: [Opensvcdecoder-support] Problem decoding IDR pictures
>  
> Hello Selim,
> 
> I know that I have problems with MGS case, but it depends of the encoding parameters.
> For example, the decoder is compatible with the following stream (SVCBMT-13.264)  which is part from the conformance testing of the SVC standard.
> This stream has three layers, DqId equals to 0, 1 or 2.
> 
> I have also several others streams with different configurations in which MGS layers have dependency_id different from 0. And the decoder is able to decode correctly these streams.
> 
> If you can provide me streams and configuration files for the case where OpenSVCDecoder is not compatible with.
> 
> Kind regards
> 
> Médéric
> 
> 
> 
> sel...@or... a écrit :
> Hello again,
>  
> Reporting on MGS case: I have tested some scenarios and I noticed that MGS is fine only with one layer on top of the base layer, i.e L0Q0 – L0Q1 works. I have also test L0Q0-L0Q1-L1Q0 and it works fine. However these cases are not supported by the OpenSVC Decoder:
> More than one MGS Layer on top of the base layer
> Any MGS layer with L > 0
> That means the only case it works Q=1 and L=0.
> I hope this could help any future work on this issue.
>  
> Best regards,
> Selim   
>  
> De : mblestel [mailto:med...@in...] 
> Envoyé : vendredi 11 juin 2010 17:34
> À : ELLOUZE Selim RD-CORE-LAN
> Cc : ope...@li...; mr...@in...
> Objet : Re: Problem decoding IDR pictures
>  
> 
> Hello Selim,
> 
> First, thank you for using Open SVC Decoder.
> 
> The problem was due to negative POC, which are authorized in the SVC standard.
> The modifications can be found under the revision 171 of the SVN repository.
> 
> Concerning constraints in configuration files, Open SVC Decoder is not compatible with MGSVector.
> These following lines should be removed from configuration files:
> MGSVectorMode 1
> MGSVector0 4
> MGSVector1 4
> MGSVector2 8
> 
> 
> Kind regards
> 
> Médéric
> 
> sel...@or... a écrit :
> Hello,
>  
> I have got some troubles trying decoding a sequence with IDR pictures. The SVC stream is decoded properly except that when decoding an IDR picture, a sort of comeback occurs. It is like the stream is paused, played back and then restarts being decoded properly. However changing the spatial resolution is not affected.
>  
> When I checked the JSVM encoder output, I found this stream structure (which I think is the source of the problem):
> AU     0: I    T0 L0 Q0   QP 34   Y 31.2299  U 41.3298  V 42.2093     13568 bit
> AU     0: I    T0 L1 Q0   QP 34   Y 31.1768  U 41.8522  V 42.5728     55392 bit
> AU    -8: P    T1 L0 Q0   QP 38   Y 30.3367  U 41.6256  V 42.7728      5664 bit
> AU    -8: P    T1 L1 Q0   QP 38   Y 30.2618  U 42.3020  V 42.4606     34912 bit
> AU   -12: P    T2 L0 Q0   QP 39   Y 30.0292  U 41.6095  V 42.7954      3280 bit
> AU   -12: P    T2 L1 Q0   QP 39   Y 29.9022  U 42.2241  V 42.2924     27568 bit
> AU   -14: P    T3 L0 Q0   QP 40   Y 29.7667  U 41.6960  V 42.9154      1440 bit
> AU   -14: P    T3 L1 Q0   QP 40   Y 29.2568  U 42.2922  V 42.3649     13952 bit
> AU   -15: P    T4 L0 Q0   QP 42   Y 29.6208  U 41.6600  V 42.9284       728 bit
>  
> I suspect the « - » ordered pictures to trouble the decoder.
> Please find attached the configuration files I used and the encoder output.
>  
> I tested you video_2 sequence and I noticed that we could change spatial resolution without problems so it should include IDR pictures. I was wondering if there are any constraints to include in the JSVM configuration files in order to have the stream work properly with Open SVC Decoder.
>  
> Best regards,
> Selim
>  
>  
>  
> 
> --
> Médéric Blestel
> Ingénieur de Recherche / Research Engineer
> 
> 
> 
> 
> 
> IETR/Groupe Image 
> 
> 
> 
> 
> 
> INSA DE RENNES
> 20 AVENUE DES BUTTES DE COESMES
> CS 70 839
> 35 708 RENNES CEDEX 7
> 
> Tél : +33 (2) 23 23 85 67
> <image001.gif>
> <image002.jpg>
>  
>  
>  
> 
> 
> 
> 
>  
>  
>  
>  
>   
>  
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
>  
>  
> 
> 
> 
> 
>  
>  
>  
>  
>   
>  
> _______________________________________________
> Opensvcdecoder-support mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensvcdecoder-support
>   
>  
> 
> --
> Médéric Blestel
> Ingénieur de Recherche / Research Engineer
> 
> 
> 
> 
> IETR/Groupe Image 
> 
> 
> 
> 
> INSA DE RENNES
> 20 AVENUE DES BUTTES DE COESMES
> CS 70 839
> 35 708 RENNES CEDEX 7
> 
> Tél : +33 (2) 23 23 85 67
> <image001.gif>
> <image002.jpg>
>  
>  
> 
> --
> Médéric Blestel
> Ingénieur de Recherche / Research Engineer
> 
> 
> 
> IETR/Groupe Image 
> 
> 
> 
> INSA DE RENNES
> 20 AVENUE DES BUTTES DE COESMES
> CS 70 839
> 35 708 RENNES CEDEX 7
> 
> Tél : +33 (2) 23 23 85 67
> <image001.gif>
> <image004.jpg>
>  
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
> Opensvcdecoder-support mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensvcdecoder-support
>  