Dear All - With regard to Section 2.1 Internet Protocol Television (IPTV) and Table 1. I note that the use case states "Typical content used in this application is movies, cartoons, series, TV shows, etc."
Table 1 lists 1080p at 24, 50 and 60 fps, and while these resolution/frame rates may be used they do not represent typical content formats that a US Broadcaster (e.g. CBS) delivers; a very typical format for the typical content types noted is 1080i at 59.94 fields per second (29.97 frames per second) and I suggest that this be added to Table 1 as a typically delivered content type. I'd also point out that 2160p @ 30 may be used in limited cases however the frame rate is too low for most content (particularly Sports) and that at the resolution of 2160p, 59.94 frames per second is a more realistic and necessary use case. I suggest that this also be added to Table 1. greg ________________________________________ From: video-codec [[email protected]] on behalf of Thomas Daede [[email protected]] Sent: Thursday, July 02, 2015 4:54 PM To: [email protected] Subject: [video-codec] Comments on draft-filippov-netvc-requirements-00 First of all, thank you for submitting this draft! I will be the one working on merging any remaining parts of draft-moffitt-netvc-requirements-00 into your draft. I have some comments about your draft, organized by section. 2.1. Internet Protocol Television (IPTV) I don't think either error robustness or temporal scalability are necessary here. This sort of content is usually delivered over a reliable network with high latency, like TCP. Also, I would really like to not support interlacing. I would suggest removing the interlaced formats and recommending a deinterlacer be used before encoding. 2.2. Video conferencing I would suggest dropping all of the CIF/SIF/nonsquare pixel formats. 480p and 360p could replace them. 2.3. Video sharing So the main difference between 2.3 and 2.1 seems to be the content source. I would suggest replacing section 2.1 with 2.3 entirely. 2.4. Screencasting It should probably be made clear that these are input formats, but not necessarily what the encoder will run at. I would expect a reasonable encoder to convert RGB to YCbCr or YCgCo internally. In addition, high frame drop is really common for screencasting, for effective frame rates of 15fps or less. 2.5. Game streaming Why is this the only category that requires resolution scalability? 3.1. Basic requirements Is the intent that all decoders should support decoding 8 and 10 bit bitstreams? Also, maybe swap 4:2:2 with 4:4:4, as 4:2:2 isn't in any of the usecases mentioned earlier. 4.1. Compression performance evaluation Are you suggesting running all of the codecs in CBR mode? I don't think this makes sense for many of the applications mentioned earlier. In addition, you are going to need to specify CBR buffer sizes, etc. The equation you give seems to give the rate over the whole file, which I would normally consider VBR. Also, I'm not sure how much of this belongs in this draft versus the testing draft. _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
_______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
