Okay, thanks I will patch that
Le sam. 24 août 2019 à 20:09, Marton Balint <c...@passwd.hu> a écrit : > > > On Fri, 23 Aug 2019, Anthony Delannoy wrote: > > >> I think we should only merge the part of this patchset which makes the EIT > >> available as a data stream. Parsing the whole EIT or dumping the data as > >> ASCII is not libavcodec's or libavutil's job. > > > > The EPG decoder does not change the table's data, it just store them > > and it happens to > > contains text sometimes. > > Some utilites functions I made in libavutil/dvb can convert those raw > > data in text > > description(s) for certain descriptors. > > > >> Also there is no such concept in libavcodec as a data decoder, if > >> something happens to > >> work with avcodec_send_packet/avcodec_receive_frame that is mostly luck I > >> believe. > > > > avcodec_send_packet and avcodec_receive_frame both call > > AVCodec::receive_frame if it is > > implemented. That's why my implementation of the EPG decoder does > > contain this function. > > > > For now my test scripts consists to: > > ``` > > 99 if (st->codecpar->codec_id != AV_CODEC_ID_EPG) > > 100 goto free_pkt; > > 101 > > 102 ret = avcodec_send_packet(dec_ctx, &pkt); > > ... > > 112 while (1) { > > 113 ret = avcodec_receive_frame(dec_ctx, frame); > > 114 if (ret < 0) > > 115 break; > > 116 > > 117 for (int i = 0; i < frame->nb_side_data; i++) { > > 118 AVFrameSideData *sd = frame->side_data[i]; > > 119 if (sd && sd->type == AV_FRAME_DATA_EPG_TABLE) { > > 120 EPGTable *table = sd->data; > > 121 av_epg_show_table(table, AV_LOG_WARNING); > > 122 } > > 123 } > > 124 av_frame_unref(frame); > > 125 } > > 126 > > 127 free_pkt: > > 128 av_packet_unref(&pkt); > > ``` > > It works as intended and permits to decode EPGTable without issues, I > > tried on multiple channels. > > > > I wanted to permit the table decoding and not just an EPG data stream > > to permit easy reading > > and in the future easy modification before encoding EPG back. > > > >> I am also not sure if we should add the EIT PID to all programs, that > >> would mess up the direct relation between a PMT and an AVProgram, and we > >> probably don't want that. So I'd rather see the EIT data stream as a > >> standalone PID separate from the programs. > > > > I'm not an expert but I think each service/program contains a PMT > > table and all others. So one > > EPG stream (if available) for each service. > > That's what I understood from the ETSI EN 300 468 V1.16.1 > > The EPG stream is a single stream in the whole TS, it is on a single PID. > The PMTs do not reference the EIT PID, therefore we should not make the > EPG stream part of the programs, even if the EPG stream can contain the > schedule of the programs. > > Regards, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".