Yes, this test is mpegts over UDP. Yes, the new stream comes with a new PID, so I didn't see a way to check if the PIDs match when I get the packet, since the AVPacket only has the stream index.
The kludge I put in was to initialize the streamIndex to the last video stream in the list (I was initializing it to the first video stream). When the AVPacket.stream_index doesn't match, then recheck the stream list in the AVFormatContext to see if a new stream has been added, update my stored index to the new last video stream's index, and then compare against the received packet. However, I'd really like to know when a new stream is added, or at least get an error indicator (e.g., an EOF). Michael On Mon, Apr 7, 2014 at 4:45 PM, Luca Barbato <[email protected]> wrote: > On 07/04/14 22:21, Michael Rice wrote: > > I have setup an application to receive and decode an UDP video stream and > > it's working fine. During initialization, I loop through all of the > streams > > in the AVFormatContext and use the first video stream, and I remember > that > > stream index. As I'm looping to receive packets using av_read_frame(), I > > check the AVPacket.stream_index to make sure I only process packets with > > the same stream index I found during initialization. If it's the same > > stream index, I decode it and process it. > > > > This all works fine, except in one circumstance. I'm using VLC to > generate > > the UDP stream, and it's simply looping an input file. When VLC gets > loops > > back to the beginning of the file, I don't get any error code returned > from > > av_read_frame(), but the packet that it reads has a different > stream_index; > > it is incremented by 1. Subsequently, my check to ensure I'm processing > the > > correct stream will fail, because all of a sudden the packets have a new > > stream_index. > > Are you using mpegts over UDP ? Does the different stream comes with a > different PID (check the st->id)? > > > Is there some other indicator I can use to know this happened? I can put > > some code in to try and infer this condition, and start processing the > new > > stream, but I would really much rather have a definitive indicator that > the > > stream_index has changed for a reason. > > mpegts must assume additional/different streams would appear over time. > > > Here's some pseudo code showing what I'm doing: > > > > AVFormatContext* fc = 0; > > AVCodecContext* cc = 0; > > AVCodec* codec = 0; > > int streamIndex = -1; > > initialize(char* url) > > { > > fc = avformat_alloc_context(); > > avformat_open_input(&fc, url, 0, 0); > > avformat_find_stream_info(fc, 0); > > for(int index = 0; index < fc->nb_streams; ++index) > > { > > if(fc->streams[index]->codec->codec_type == AVMEDIA_TYPE_VIDEO) > > { > > streamIndex = index; > > cc = fc->streams[streamIndex]->codec; > > codec = avcodec_find_decoder(cc->codec_id); > > break; > > } > > } > > if(codec == 0) > > { > > exit(0); > > } > > avcodec_open2(cc, codec, 0); > > } > > > > readVideo() > > { > > while(1) > > { > > AVPacket* packet = new AVPacket(); > > int readStatus = av_read_frame(fc, packet); > > if(readStatus < 0) > > { > > // Do error handling > > } > > else > > { > > // ----> This is where the AVPacket.stream_index shows up incremented > after > > VLC loops the video > > Check for the fc->streams[packet->stream_index]->id > > > if(packet->stream_index != streamIndex) > > { > > av_free_packet(packet); > > continue; > > } > > > > // ... continue to decode and process packet ... > > } > > } > > } > > lu > > _______________________________________________ > libav-api mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-api > _______________________________________________ libav-api mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-api
