From: Médéric B. <Med...@in...> - 2011-10-11 08:59:04
|
Dear Alberto, The stand alone project and mplayer do not use the same method to parse H264/SVC video streams. In the stand alone project, the parsing is done by Access Unit, that's why the decoding process is mostly going right. In mplayer, the parsing should be done the same way (AU by AU), by it has been developped to work with AVC videos. So, on decoding SVC video streams, errors can occur into the decoding process because AU are not well transmited to the decoder. The mplayer parser should be modify to be fully compliant with the SVC standard. Regards, Médéric Le 05/10/2011 18:41, alberto alvarez gonzález a écrit : > Hi all > > I am working with both standalone and mplayer implementations of SVC > decoder. > It happens that with mplayer some frames are not properly decoded at > the begining of the sequence while with the latest updates made to > the standalone it decodes correctly all the frames. > > I have noticed that got_picture=0 (i.e. ImgToDisplay=0) for all slices > for frames between 2 and 11 or so. > But with PC.c, it is able to extract the frames correctly. AFAIK, the > problem resides in these decoding functions. > > I tested this with a fresh svn version 287 and still the same issue. > The numbers below are for video_1.264 > > I get that both functions are essentially doing the same stuff. I have > tried myself to compare both and provide a solution, > But to date, I have failed to find the difference that is causing the > problem. > > Maybe I am doing something wrong. I just issued a simple dirty printf > in the latest svn code for both functions > This one for main in PC.c for standalone > > printf("VP_addr %08i Type %02i VP_ImgToDisplay %i size=%ix%i > MaxTempId %i TempIdToDisplay %i CurrentNalTempId %i \n", > *decoder_svc_Nal_Compute_CondO5_o, > decoder_svc_NalUnit_NalUnitType_io[0], > decoder_svc_Nal_Compute_CondO1_o[0], > *decoder_svc_Nal_Compute_CondO6_o, > *decoder_svc_Nal_Compute_CondO7_o, > DqIdNextNal_Nal_o->MaxTemporalId, > DqIdNextNal_Nal_o->TempToDisplay, > DqIdNextNal_Nal_o->TemporalId > ); > > That gives 500 lines with "ImgToDisplay 1" > This one for decodeNAL for H264_plg.c in Libs/CommonFiles/src > > printf("VP_addr %08i Type %02i VP_ImgToDisplay %i size=%ix%i > MaxTempId %i TempIdToDisplay %i CurrentNalTempId %i \n", > RAM_tcpmp_alloc_->decoder_svc_Nal_Compute_CondO5_o[0], > RAM_tcpmp_alloc_->decoder_svc_NalUnit_NalUnitType_io[0], > RAM_tcpmp_alloc_->decoder_svc_Nal_Compute_CondO1_o[0], > RAM_tcpmp_alloc_->decoder_svc_Nal_Compute_CondO6_o[0], > RAM_tcpmp_alloc_->decoder_svc_Nal_Compute_CondO7_o[0], > RAM_tcpmp_alloc_->DqIdNextNal_Nal_o->MaxTemporalId, > RAM_tcpmp_alloc_->DqIdNextNal_Nal_o->TempToDisplay, > RAM_tcpmp_alloc_->DqIdNextNal_Nal_o->TemporalId > ); > That gives 488 lines with "ImgToDisplay 1" and issuing a log in > libavcodec/h264.c I get 11 lines with got_picture = 0 > > With video_5.264 i get 484 of 500 frames with ImgToDisplay=1 with > mplayer (500 with standalone) > > I hope to help with this sort of "bug" report. > > Thank for the excellent work. Best regards, > > Alberto > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > > > _______________________________________________ > Opensvcdecoder-support mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensvcdecoder-support -- Médéric Blestel Ingénieur de Recherche / Research Engineer Institut d' Electronique et de Télécommunications de Rennes (IETR) UMR CNRS 6164 Tél : +33 (2) 23 23 85 67 Fax : +33 (2) 23 23 82 62 IETR/Groupe Image INSA DE RENNES 20 AVENUE DES BUTTES DE COESMES CS 70 839 35 708 RENNES CEDEX 7 |