Pvrparse #1464
Pvrparse #1464
Conversation
ghost
assigned 
|
I have one concern about this. I'm not sure how the ffmpeg parsers will behave on bad quality streams. there is a risk it will sucessfullly parse invalid data, leading to codec info changes that should not have occured. But i suspect only way to find out is to test it. |
|
@opdenkamp @FernetMenta you might be interested in testing this stuff out. You have more experience with pvr stuff than me. |
|
If I understand this correctly, this should ease handling of SD <-> HD switches in streams, so that addons dont have to report those switches. Will this also work on buffers like timeshift (backend side for now, like the 4tr and MP support) and especially when seeking in mixed ones? ----- Reply message ----- should reduce the burden on addons to provide data we need to init codecs. This suffers same behaviour as the extradata parsing. On startup we will attempt to open a stream, without full knowledge of it's internals. This mean we will potentially re-open it again after first packet. You can merge this Pull Request by running: Commit Summary dvdplayer: make level available for audio as well File Changes M xbmc/cores/dvdplayer/DVDDemuxers/DVDDemux.h (8) Patch Links https://github.com/xbmc/xbmc/pull/1464.patch — Reply to this email directly or view it on GitHub. |
|
Will test this as soon as I have a chance. From what I can see so far is that either for tvheadend or vdr an immediate re-open will happen. tvheadend reports a height of 1088 on hd channels whereas vnsi reports the cropped height 1080. |
|
ditto, will test asap Op 23-09-12 09:25, Rainer Hochecker schreef:
|
|
Anyway we can get frame_mbs_only_flag from sps ? That way we know that it 'might' be interlaced and can vector to a decoder that can handled h264 interlaced ? Right now for VDA/VTB, we parse extradata and only accept if frame_mbs_only_flag is 1 (signaling progressive), if 0, then it's either interlaced, paff or mbaff and we can only tell progressive vs interlaced frame usage by looking at individual frames. Currently we try VDA/VTB and bail on such content, it would be nicer to use this info in codec factory to pick a suitable codec and skip the whole try/fail/try/fail path. |
|
Imho try fail is the right approach. Codec factory shouldn't need to know |
|
Factory codec already qualifies the codec type (mpeg2, h264, etc) and software/hardware flag. I don't see why qualifying the type of h264 is any different. Try/fail/try/fail is very inefficient, it sucks resources loading/unload things and delays the time it takes to spin up video playback. |
| #define CHECK_UPDATE(st, trg, src, invalid) do { \ | ||
| if(src != invalid \ | ||
| && src != st->trg) { \ | ||
| st->trg = src; \ |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
I have tested this for 2 evenings on my living room box (vnsi). Apart from the log mentioned above no negatives. Although PVR streams don't have profile and level set, the increase of the change counter does not harm when done on the first packet. I like this idea of parsing the streams very much. Maybe in a next step only validated streams can be accepted. |
|
bump - something for Frodo? @cptspiff |
|
Yes probably, have not heard of any major issues with it. It puts less |
|
+1 |
This also remove the redundant iProfile in a video stream
1) make sure that we increase the timeout for loading things with checkFiles=1 to 60 seconds instead of 10. 2) don’t send X-Plex-Container options to the metadata endpoints so we can cache it properly 3) increase the default read-timeout to 30 instead of 10 seconds. Related to xbmc#1464
This will continuously parse input streams from PVR manager for changes in codec parameters. This
should reduce the burden on addons to provide data we need to init codecs.
This suffers same behaviour as the extradata parsing. On startup we will attempt to open a stream, without full knowledge of it's internals. This mean we will potentially re-open it again after first packet.